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

<p>в течение последних нескольких месяцев я изучал linux (fedora 10, затем 11) (и мне это очень нравится - это все равно, что снова и снова открывать для себя компьютеры, так много всего нужно изучить).</p><p>я добавил своего пользователя в последнюю строку файла/etc/sudoers, как показано ниже, чтобы меня не спрашивали мой пароль при выполнении команды sudo:</p><blockquote> <p>myusername all = (all) nopasswd: all</p> </blockquote><p>теперь каждый раз, когда я выполняю команду с помощью sudo, она приостанавливает заметное количество времени перед тем, как фактически выполнить задачу (~ 10 секунд). почему это может быть и как я могу это исправить? я использую sudo версии 1.7.1 на fedora 11 x86 64.</p>

<p>я задал этот вопрос на so, и он был перенесен сюда. это говорит о том, что у меня больше нет возможности редактировать вопрос, как если бы он мне принадлежал, или даже принять правильный ответ, но это оказалось чтобы быть истинной причиной, почему и как ее решить:</p><p> <a href="http://www.linuxquestions.org/questions/linux-newbie-8/fedora-11-sudo-has-a-20-second-start-delay-732291/#post3575840">найдено здесь</a> пользователь "rohandhruva" там дает правильный ответ:</p><blockquote> <p>это происходит, если вы меняете имя хоста в процессе установки.</p> <p>чтобы решить проблему, отредактируйте файл/etc/hosts</p> <pre><code>127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <add\_yours\_here> ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <add\_yours\_here> </code></pre></blockquote>

<p>убедитесь, что ваш демон syslog работает правильно; это вызвало проблему для меня.</p><p>запустите следующую команду</p><pre><code>logger 'hello world' </code></pre><ol> <li> <p>возвращается ли команда в течение разумного периода времени?</p> </li> <li> <p>'hello world' появляется в <code>/var/log/syslog</code>?</p> </li> </ol><p>если это не так, демон syslog потерпел крах. перезапуск должен исправить вашу проблему.</p>

<p>является ли один из файлов/каталогов, которые он должен прочитать при подключении к сети, или это как-то вызывает чтение с медленного usb-устройства? попробуйте strace и посмотрите, где это медленно; если это пройдет слишком быстро, сделайте</p><pre><code>sudo strace -r -o trace.log sudo echo hi </code></pre><p>каждая строка будет начинаться со времени, прошедшего с момента ввода предыдущего системного вызова.</p><p>(первоначальное судо кажется необходимым; я не знаю, насколько это повлияет на результаты.)</p>

<p>я недавно обнаружил, что у меня была такая же проблема. не было никакой задержки судо, а затем внезапно, около 10-20 секунд. я определил конкретную проблему, используя:</p><pre><code> 1. chmod u+s /usr/sbin/strace (as the root user) </code></pre><p>как себя</p><pre><code> 1. sudo -k 2. strace sudo /bin/tcsh </code></pre><p>а потом найдите, где висят системные вызовы.</p><p>в моем случае я обнаружил, что он зависает при переводе dns, по-видимому, один из dnsen в моем списке на <code>/etc/resolv.conf</code> был очень шумным или испортился. поэтому я изменил порядок разрешения, и пуф снова сработал быстро.</p>

<p>у меня та же проблема, я проверил /var/log/auth.log и syslog на наличие ошибок. оказывается, что мой сервер ldap не мог быть достигнут, и это замедлило все.</p><p>я больше не использовал аутентификацию на основе ldap, поэтому я удалил все ссылки "ldap" из /etc/nsswitch.conf</p><p>с тех пор все снова работает как шарм.</p>

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

<p>я не уверен насчет fedora, но я использовал другие системы, в которых sudo проверил бы, откуда вы вошли, что, если ваш dns не настроен должным образом, может занять много времени. это также можно увидеть, когда ssh подключается к машине - требуются целые годы, чтобы создать приглашение.</p>

<h2>selinux чехол</h2><p>если одна и та же команда sudo <strong> медленная только в демоне </strong> и быстрая в командной строке, то это вызвано <strong> selinux </strong> наиболее вероятно. (selinux = nsa модуль ядра linux с улучшенной безопасностью, включен в fedora по умолчанию.)</p><p>типичным случаем является http-сервер и специальный скрипт для управления сервером, ограниченный в <code>sudoers</code>:</p><pre><code>apache all=(root\_or\_user) nopasswd: /full/path/the\_safe\_command </code></pre><p>в этом случае типично, что ничего о selinux не сообщается в журнале аудита <code>ausearch -m avc -ts today</code>, но сценарий будет работать быстро, если мы временно отключим принудительное выполнение с помощью <code>setenforce 0</code>. (а затем снова включите с помощью <code>setenforce 1</code>)</p><p>единственные релевантные сообщения в системном журнале (journalcrl) - это после задержки 25 секунд:</p><blockquote> <p>... sudo [...] pam\_systemd (sudo: session): не удалось создать сессию: не получил ответ. возможные причины: удаленное приложение не отправило ответ, политика безопасности шины сообщений заблокировала ответ, истекло время ожидания ответа или было разорвано сетевое соединение.<br> ... sudo [...]: pam\_unix (sudo: session): сеанс открыт для пользователя root с помощью (uid = 0)</p> </blockquote><p>ведение журнала всех сообщений selinux "не выполнять аудит" может быть включено с помощью <code>semodule -db</code> и снова отключен <code>semodule -b</code>.<br> (я надеюсь, что скоро напишу здесь модуль политики selinux для этого случая или можно использовать метод из <a href="https://serverfault.com/a/617766/57359">этот ответ</a> .)</p>

<p>для меня это был krb5-user/config/locales. я заметил это, изучив /var/log/auth.log. использование apt-get remove для удаления исправленных пакетов. не удаляйте эти пакеты, если вы находитесь на компьютере, требующем kerberos (pam\_krb5).</p>

<p>проверьте файл/etc/hosts и убедитесь, что у вас есть запись для 127.0.0.1</p><p>( <a href="http://forums.fedoraforum.org/showthread.php?t=210503">источник</a> )</p>

<p>после устранения проблем с хостом убедитесь, что вы удалили все поврежденные кеши dns, если у вас запущено приложение кеширования dns, например nscd:</p><pre><code>/etc/init.d/nscd force-reload </code></pre>

<p>посмотрев на имеющийся у меня пример файла <code>sudoers</code>, я считаю, что после бита <code>nopasswd:</code> должен быть пробел.</p>

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

<p><strong>системный случай</strong></p><p>для меня в моей системе не хватило памяти, и многие процессы потерпели крах. моя система основана на systemd, и что-то там потерпело крах. мне сложно вспомнить все, что я делал, но:</p><ul> <li><code>systemctl status <any.service></code> будет время ожидания</li> <li>я не мог <code>sudo reboot</code> (на основе системы)</li> </ul><p><strong>solution</strong></p><p>перезапуск исправил мою проблему, но для меня это было просто бинтом. вам все еще нужно выяснить, почему у вас закончилась память/произошел сбой.</p>

<p>вы используете ldap для аутентификации?</p><p>если это так, вы, вероятно, хотите использовать мягкую политику привязки. в /etc/ldap/ldap.conf (или /etc/ldap.conf):</p><pre><code>bind\_policy soft </code></pre>