Tại sao lệnh sudo mất nhiều thời gian để thực thi?

Tôi đã chọn Linux (Fedora 10, rồi 11) trong vài tháng qua (và tận hưởng nó vô cùng - nó giống như khám phá máy tính một lần nữa, rất nhiều điều để học).

Tôi đã thêm người dùng của mình vào dòng cuối cùng của tệp / etc / sudoers như bên dưới, để tôi không bị hỏi mật khẩu khi thực hiện lệnh sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Bây giờ mỗi khi tôi thực thi một lệnh bằng sudo, nó sẽ tạm dừng một lượng thời gian đáng chú ý trước khi thực sự thực hiện nhiệm vụ (~ 10 giây). Tại sao điều này có thể và làm thế nào tôi có thể khắc phục điều này? Tôi đang chạy phiên bản Sudo 1.7.1 trên Fedora 11 x86 64.

Tôi đã hỏi câu hỏi này trên SO và nó đã được chuyển đến đây. Điều đó nói rằng tôi không còn khả năng chỉnh sửa câu hỏi như thể tôi sở hữu nó, hoặc thậm chí chấp nhận câu trả lời đúng, nhưng điều này hóa ra là lý do thực sự tại sao và làm thế nào để giải quyết nó:

Tìm thấy ở đây Người dùng "rohandhruva" trên đó đưa ra câu trả lời đúng:

Điều này xảy ra nếu bạn thay đổi tên máy chủ trong quá trình cài đặt.

Để giải quyết vấn đề, chỉnh sửa tệp / etc / hosts

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>

Kiểm tra xem daemon syslog của bạn có hoạt động chính xác không; Điều này gây ra vấn đề cho tôi.

Chạy lệnh sau

logger 'Hello world'

1. Liệu lệnh trở lại trong một khoảng thời gian hợp lý?

2. 'Hello world' có xuất hiện /var/log/syslogkhông?

Nếu đây không phải là trường hợp, trình nền syslog đã bị hỏng. Khởi động lại nó sẽ khắc phục vấn đề của bạn.

Là một trong những tập tin / thư mục cần đọc trên giá treo mạng, hay bằng cách nào đó nó kích hoạt việc đọc từ thiết bị usb chậm? Hãy thử sải bước và xem nơi nào chậm; nếu nó đi quá nhanh, hãy làm

sudo strace -r -o trace.log sudo echo hi

Mỗi dòng sẽ bắt đầu với thời gian thực hiện kể từ khi vào tòa nhà trước đó.

(Sudo ban đầu dường như là cần thiết; tôi không biết bao nhiêu sẽ làm xáo trộn kết quả.)

Gần đây tôi thấy rằng tôi có cùng một vấn đề. Không có độ trễ sudo và sau đó đột ngột, khoảng 10-20 giây chậm trễ. Tôi đã xác định vấn đề cụ thể bằng cách sử dụng:

 1. chmod u+s /usr/sbin/strace  (as the root user)

Như chính bạn:

 1. sudo -K
 2. strace sudo /bin/tcsh

Và sau đó tìm nơi các cuộc gọi hệ thống được treo.

Trong trường hợp của tôi, tôi thấy rằng nó được treo trên một bản dịch DNS, rõ ràng một trong những DNSen trong danh sách của tôi /etc/resolv.conflà rất hay bị hỏng. Vì vậy, tôi đã thay đổi thứ tự giải quyết và mọi thứ trở nên nhanh chóng trở lại.

Tôi không chắc chắn về Fedora, nhưng tôi đã sử dụng các hệ thống khác, nơi sudo sẽ kiểm tra xem bạn đã đăng nhập từ đâu, nếu DNS của bạn không được thiết lập tốt có thể mất nhiều thời gian chờ. Điều này cũng có thể được nhìn thấy khi SSH vào máy - phải mất nhiều thời gian để đưa ra lời nhắc.

Tôi có cùng một vấn đề, tôi đã kiểm tra /var/log/auth.log và syslog để tìm lỗi. Hóa ra máy chủ LDAP của tôi không thể truy cập được và nó làm chậm mọi thứ.

Tôi không sử dụng auth dựa trên LDAP nữa, vì vậy tôi đã xóa tất cả các tham chiếu "ldap" khỏi /etc/nsswitch.conf

Kể từ đó mọi thứ hoạt động như một sự quyến rũ một lần nữa.

Trong trường hợp có thể, nó được tìm thấy tên máy chủ (được cấu hình trong /etc/sysconfig/ mạng) không tồn tại trong /etc/hoststệp; vì vậy khi thêm vào tệp đã đề cập ở trên, tệp sẽ mở ngay lập tức.

Tôi gặp một vấn đề tương tự, tôi đã sửa nó bằng cách đặt cả tên máy chủ (ví dụ: mybox) và đầu ra đầy đủ của lệnh tên máy chủ (mybox.mydomain.com). Điều này xóa nó ngay lên. Đã đi từ 2 phút để mở / etc / hosts để truy cập tức thời.

Vỏ hộp

Nếu cùng một lệnh sudo chỉ chậm trong một daemon và nhanh trên dòng lệnh, thì đó có thể là do SELinux gây ra . (SELinux = Mô-đun hạt nhân Linux được tăng cường bảo mật NSA, được bật trong Fedora theo mặc định.)

Một trường hợp điển hình là máy chủ http và tập lệnh đặc biệt để quản lý máy chủ, bị hạn chế trong sudoers:

apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command

Điển hình trong trường hợp này là không có gì về SELinux được báo cáo trong nhật ký kiểm toán ausearch -m avc -ts today, nhưng tập lệnh sẽ diễn ra nhanh nếu chúng ta tạm thời vô hiệu hóa việc thi hành bởi setenforce 0. (và sau đó bật lại bằng cách setenforce 1)

Các thông báo có liên quan duy nhất trong nhật ký hệ thống (tạp chí) là những thông báo sau 25 giây chậm trễ:

... sudo [...] pam_systemd (sudo: session): Không thể tạo phiên: Không nhận được trả lời. Các nguyên nhân có thể bao gồm: ứng dụng từ xa không gửi trả lời, chính sách bảo mật bus tin nhắn đã chặn trả lời, hết thời gian trả lời hoặc kết nối mạng bị hỏng.
... sudo [...]: pam_unix (sudo: session): phiên được mở cho người dùng root bởi (uid = 0)

Ghi nhật ký của tất cả các tin nhắn SElinux "không kiểm toán" có thể được bật semodule -DBvà tắt lại bằng cách semodule -B.
(Tôi hy vọng rằng tôi sẽ sớm viết mô-đun chính sách SELinux cho trường hợp này tại đây hoặc có thể sử dụng phương pháp từ câu trả lời này .)

Từ việc nhìn vào sudoerstập tin mẫu mà tôi có, tôi tin rằng có một khoảng trống sau NOPASSWD:bit.

Kiểm tra tệp / etc / hosts của bạn và đảm bảo rằng bạn có một mục nhập cho 127.0.0.1

( nguồn )

Sau khi khắc phục mọi sự cố máy chủ, hãy đảm bảo bạn xóa mọi bộ đệm DNS xấu nếu bạn đang chạy một ứng dụng bộ đệm DNS như nscd:

/etc/init.d/nscd force-reload

Đối với tôi, đó là krb5-user / config / loc đang được cài đặt. Tôi nhận thấy điều này bằng cách kiểm tra /var/log/auth.log. Sử dụng apt-get remove để gỡ cài đặt các gói đó. Đừng xóa các gói đó nếu bạn đang sử dụng máy tính yêu cầu kerberos (pam_krb5).

Bạn đang sử dụng LDAP để xác thực?

Nếu vậy bạn có thể muốn sử dụng chính sách ràng buộc mềm. Trong /etc/ldap/ldap.conf (hoặc /etc/ldap.conf):

bind_policy soft

Âm thanh như bạn có một số loại thời gian chờ trong chuỗi xác thực của bạn. Kiểm tra xem sudo cố gắng xác thực và theo dõi các tắc nghẽn.

Vỏ hệ thống

Đối với tôi, hệ thống của tôi đã hết bộ nhớ và rất nhiều quá trình bị hỏng. Hệ thống của tôi dựa trên systemd và một cái gì đó trong đó đã bị hỏng. Thật khó để tôi nhớ mọi thứ tôi đã làm, nhưng:

• systemctl status <any.service> sẽ hết thời gian
• Tôi không thể sudo reboot(dựa trên systemd)

Giải pháp

Một khởi động lại đã khắc phục vấn đề của tôi, nhưng đối với tôi chỉ là một chiếc băng đô. Bạn vẫn cần tìm hiểu lý do tại sao bạn hết bộ nhớ / bị rơi.