Почему выполнение команды sudo занимает много времени?

За последние несколько месяцев я выбирал Linux (Fedora 10, а затем 11) (и мне это очень нравится - это все равно, что снова и снова открывать для себя компьютеры, так много всего нужно изучить).

Я добавил своего пользователя в последнюю строку файла / etc / sudoers, как показано ниже, чтобы при запросе команды sudo меня не спрашивали мой пароль:

MyUserName ALL = (ALL) NOPASSWD: ALL

Теперь каждый раз, когда я выполняю команду, используя sudo, она приостанавливает заметное количество времени перед тем, как фактически выполнить задачу (~ 10 секунд). Почему это может быть и как я могу это исправить? Я использую Sudo версии 1.7.1 на Fedora 11 x86 64.

Я задал этот вопрос на SO, и он был перенесен сюда. Тем не менее, у меня больше нет возможности редактировать вопрос, как если бы он мне принадлежал, или даже принять правильный ответ, но это оказалось истинной причиной, почему и как ее решить:

Найденный здесь пользователь "rohandhruva" там дает правильный ответ:

Это происходит, если вы меняете имя хоста в процессе установки.

Чтобы решить проблему, отредактируйте файл / 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>

Убедитесь, что ваш демон syslog работает правильно; это вызвало проблему для меня.

Запустите следующую команду

logger 'Hello world'

1. Возвращается ли команда в течение разумного периода времени?

2. «Привет мир» появляется в /var/log/syslog?

Если это не так, демон syslog потерпел крах. Перезапуск должен исправить вашу проблему.

Является ли один из файлов / каталогов, которые он должен прочитать при подключении к сети, или это как-то вызывает чтение с медленного USB-устройства? Попробуйте strace и посмотрите, где это медленно; если это пройдет слишком быстро, сделайте

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

Каждая строка будет начинаться со времени, прошедшего с момента ввода предыдущего системного вызова.

(Первоначальный sudo, кажется, необходим; я не знаю, насколько это повлияет на результаты.)

Я недавно обнаружил, что у меня была такая же проблема. Там не было задержки sudo, а затем внезапно, около 10-20 секунд задержки. Я определил конкретную проблему, используя:

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

Как себя

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

А потом найдите, где висят системные вызовы.

В моем случае я обнаружил, что он зависает при переводе DNS, по-видимому, один из DNSen в моем списке /etc/resolv.confбыл очень занят или испортился. Поэтому я изменил порядок разрешения, и пуф снова сработал быстро.

Я не уверен насчет Fedora, но я использовал другие системы, где sudo проверит, откуда вы вошли, что, если ваш DNS не настроен должным образом, может занять много времени. Это также можно увидеть, когда SSH подключается к машине - требуются целые годы, чтобы получить приглашение.

У меня та же проблема, я проверил /var/log/auth.log и syslog на наличие ошибок. Оказывается, что мой сервер LDAP не мог быть достигнут, и это замедлило все.

Я больше не использовал аутентификацию на основе LDAP, поэтому я удалил все ссылки "ldap" из /etc/nsswitch.conf

С тех пор все снова работает как шарм.

В некоторых случаях обнаруживается, что имя хоста (которое было настроено в /etc/sysconfig/ network) не существует в /etc/hostsфайле; поэтому при добавлении в вышеупомянутый файл, файл открывается быстро.

У меня была похожая проблема, я исправил ее, указав имя хоста (например, mybox) и полный вывод команды hostname (mybox.mydomain.com). Это прояснило это прямо. Ушел от 2 минут, чтобы открыть / etc / hosts для мгновенного доступа.

SELinux чехол

Если одна и та же команда sudo медленная только в демоне и быстрая в командной строке, то это, скорее всего, вызвано SELinux . (SELinux = NSA Security-Enhanced модуль ядра Linux, включен в Fedora по умолчанию.)

Типичным случаем является http-сервер и специальный скрипт для управления сервером, ограниченный в sudoers:

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

В этом случае типично, что ничего о SELinux не сообщается в журнале аудита ausearch -m avc -ts today, но сценарий работает быстро, если мы временно отключаем принудительное применение setenforce 0. (и затем включите обратно setenforce 1)

Единственные релевантные сообщения в системном журнале (journalcrl) - это после задержки 25 секунд:

... sudo [...] pam_systemd (sudo: session): не удалось создать сеанс: не получен ответ. Возможные причины: удаленное приложение не отправило ответ, политика безопасности шины сообщений заблокировала ответ, истекло время ожидания ответа или было разорвано сетевое соединение.
... sudo [...]: pam_unix (sudo: session): сеанс открыт для пользователя root с помощью (uid = 0)

Ведение журнала всех сообщений SElinux "не проводить аудит" можно semodule -DBотключить и снова отключить semodule -B.
(Я надеюсь, что я скоро напишу модуль политики SELinux для этого случая здесь или метод из этого ответа может быть использован.)

Глядя на sudoersфайл примера, который у меня есть, я считаю, что после NOPASSWD:бита должен быть пробел .

Проверьте файл / etc / hosts и убедитесь, что у вас есть запись для 127.0.0.1

( источник )

После устранения проблем с хостом убедитесь, что вы удалили все поврежденные кеши DNS, если у вас запущено приложение кеширования DNS, такое как nscd:

/etc/init.d/nscd force-reload

Для меня это был krb5-user / config / locales. Я заметил это, изучив /var/log/auth.log. Использование apt-get remove для удаления исправленных пакетов. Не удаляйте эти пакеты, если вы находитесь на компьютере, требующем Kerberos (pam_krb5).

Вы используете LDAP для аутентификации?

Если это так, вы, вероятно, хотите использовать мягкую политику привязки. В /etc/ldap/ldap.conf (или /etc/ldap.conf):

bind_policy soft

Похоже, у вас есть какой-то таймаут в цепочке аутентификации. Проверьте, как sudo пытается аутентифицироваться, и следите за узкими местами.

Системный чехол

Для меня в моей системе не хватило памяти, и многие процессы потерпели крах. Моя система основана на systemd, и что-то там потерпело крах. Мне сложно вспомнить все, что я делал, но:

• systemctl status <any.service> будет тайм-аут
• Я не мог sudo reboot(на системной основе)

Решение

Перезапуск исправил мою проблему, но для меня это было просто бинтом. Вам все еще нужно выяснить, почему у вас закончилась память / произошел сбой.