Я беру Linux (Fedora 10, затем 11) в течение последних нескольких месяцев (и получаю от этого огромное удовольствие - это как заново открывать для себя компьютеры, так много вещей, которым нужно научиться).
Я добавил своего пользователя в последнюю строку файла / etc / sudoers, как показано ниже, чтобы меня не спрашивали пароль, когда я выполняю команду sudo:
MyUserName 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>
Убедитесь, что демон системного журнала работает правильно; это вызвало у меня проблему.
Выполните следующую команду
logger 'Hello world'
Возвращается ли команда в разумные сроки?
Появляется ли "Hello world" в /var/log/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), так и полный вывод команды имени хоста (mybox.mydomain.com). Это полностью прояснило ситуацию. Ушло от 2 минут открывать / etc / hosts до мгновенного доступа.
Если та же команда sudo медленный только в демоне и быстро в командной строке, то это вызвано SELinux наиболее вероятно. (SELinux = NSA Security-Enhanced Linux kernel module, включен в 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 "dont-audit" можно включить с помощью 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 (на основе systemd)Решение
Перезагрузка устранила мою проблему, но для меня это была всего лишь бандаж. Вам все еще нужно выяснить, почему у вас закончилась память / произошел сбой.