it-swarm-ru.tech

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

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

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

MyUserName ALL = (ALL) NOPASSWD: ALL

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

88
Cuga

Я задал этот вопрос на 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>
130
Cuga

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

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

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

  2. 'Hello world' появляется в /var/log/syslog?

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

25
MattB

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

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

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

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

11
ysth

Я недавно обнаружил, что у меня была такая же проблема. Не было никакой задержки Судо, а затем внезапно, около 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 был очень шумным или испортился. Поэтому я изменил порядок разрешения, и пуф снова сработал быстро.

9
mdpc

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

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

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

5
Sakuraba

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

5
Zahid Hussain

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

5
Colin Coghill

SELinux чехол

Если одна и та же команда Sudo медленная только в демоне и быстрая в командной строке, то это вызвано SELinux наиболее вероятно. (SELinux = NSA Модуль ядра 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 для этого случая или можно использовать метод из этот ответ .)

3
hynekcer

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

1
Halsafar

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

( источник )

1
Ryan Emerle

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

/etc/init.d/nscd force-reload
1
Roger Smith

Посмотрев на имеющийся у меня пример файла sudoers, я считаю, что после бита NOPASSWD: Должен быть пробел.

1
Chris Jester-Young

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

0
towo

Системный случай

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

  • systemctl status <any.service> будет время ожидания
  • Я не мог Sudo reboot (на основе системы)

Solution

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

0
Eric Fossum

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

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

bind_policy soft
0
jtimberman