Чому для виконання команди sudo потрібно багато часу?

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

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

MyUserName ALL = (ВСІ) NOPASSWD: ALL

Тепер кожен раз, коли я виконую команду за допомогою sudo, вона призупиняє помітну кількість часу, перш ніж реально виконувати завдання (~ 10 секунд). Чому це може бути і як я можу це виправити? На Fedora 11 x86 64 я використовую версію Sudo 1.7.1.

Я запитав це питання на 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'

1. Чи повертається команда протягом розумного часу?

2. Чи з'являється "Hello world" /var/log/syslog?

Якщо це не так, демон системи syslog розбився. Перезапуск повинен вирішити вашу проблему.

Це один з файлів / каталогів, який він повинен читати на мережевому монтажі, чи це якимось чином викликає читання з повільного пристрою usb? Спробуйте напружуватися і побачити, де це повільно; якщо це пройде занадто швидко, зробіть

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

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

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

Нещодавно я виявив, що у мене така ж проблема. Судової затримки не було, і раптом, приблизно на 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 не вдалося дістатися, і він загальмував усе.

Я більше не використовував auth на основі LDAP, тому я видалив усі "ldap" посилання з /etc/nsswitch.conf

З того часу все знову працює як шарм.

У такому випадку знайдене ім'я хоста (яке було налаштовано в /etc/sysconfig/ мережу) не існує у /etc/hostsфайлі; тож після додавання у вищезгаданий файл файл відкриється негайно.

У мене була подібна проблема, я її виправив, розмістивши як ім'я хоста (наприклад, mybox), так і повний вихід команди hostname (mybox.mydomain.com). Це очистило це прямо. Пішла від 2 хвилин, щоб відкрити / etc / hosts для миттєвого доступу.

Справа SELinux

Якщо одна і та ж команда sudo повільна лише в демон і швидка в командному рядку, то вона, ймовірно, викликана SELinux . (SELinux = модуль ядра Linux з посиленою безпекою NSA, увімкнено у 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)

Журнал усіх заглушених "dont-audit" повідомлень 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 для аутентифікації?

Якщо так, то, ймовірно, ви хочете використовувати поліси зв’язування soft. У /etc/ldap/ldap.conf (або /etc/ldap.conf):

bind_policy soft

Здається, у вас є певний час очікування у вашому ланцюжку аутентифікації. Перевірте, як sudo намагається пройти автентифікацію та стежте за вузькими місцями.

Системний кейс

Для мене в моїй системі не вистачило пам'яті, і багато процесів вийшли з ладу. Моя система базується на systemd, і щось там вийшло з ладу. Мені важко згадати все, що я робив, але:

• systemctl status <any.service> очікується час
• Я не міг sudo reboot(на основі систематики)

Рішення

Перезапуск вирішив мою проблему, але для мене це був лише бандаїд. Вам ще потрібно з’ясувати, чому у вас закінчилося пам’ять / зазнав аварії.