Каждый раз, когда я использую sudo, он зависает перед завершением

12

Независимо от того, запрашивается ли у меня пароль или нет, он зависает между принятием аутентификации и выполнением того, что я просил. Другими словами sudo lsбудет висеть около 60 секунд.

Я не понимаю, что может быть причиной этого. Это на Centos 5, и я посмотрел selinuxи установил его как отключено и включено, но, похоже, это не имеет никакого эффекта.

linux centos sudo

— dlamblin
источник

15

От @ TheAndruu ответ на этот вопрос:

Это происходит, если вы меняете имя хоста в процессе установки. Чтобы решить проблему, отредактируйте файл / 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]

У меня была точно такая же проблема на Fedora 11, и это решило ее.

— gareth_bowles
источник

Я просто убедился, что мой $HOSTNAMEбыл установлен в 127.0.0.1линию. Это сработало. Благодарю.

— Дламблин

1

Кстати, sudo lsкак сеть использует?

— Дламблин

Это также работало для Ubuntu 16.04 - за исключением того, что мне пришлось изменить имя на 127.0.1.1 - 127.0.0.1 был localhost

— Билл Райдер

1

Иногда, когда ваш маршрут по умолчанию не установлен, такие команды, как sudo, зависают.

Попробуйте netstat -rпроверить, правильно ли установлен маршрут.

Эта машина получает свои пароли из локального файла / etc / passwd или что-то вроде ldap?

— egorgry
источник

Это не использование ldap; Я думаю, что это использует/etc/passwd

— dlamblin

/etc/passwdне используется для аутентификации, он используется для разрешения идентификатора и имени. /etc/shadowиспользуется для аутентификации.

— LiraNuna

1

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

— Майк Сэндс
источник

1

Вы должны проверить три вещи. 1. / etc / hostname 2. / etc / hosts 3. /etc/resolv.conf

Я обнаружил, что мое имя хоста было правильным, что файл hosts был неправильным, и, кроме того, resolv.conf нужно было обновить.

— Пол Дж. Барретт
источник

1

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

— Halsafar
источник

1

На это намекает ответ Halsafar : у меня включен Kerberos в моей рабочей VPN, но он бесполезен, когда я отключен, поэтому я изменил порядок модуля auth, чтобы использовать его раньше :/etc/pam.d/common-authpam_unixpam_krb5

Перед:

auth [success=4 default=ignore] pam_krb5.so ...
auth [success=3 default=ignore] pam_unix.so ...

После:

auth [success=4 default=ignore] pam_unix.so ...
auth [success=3 default=ignore] pam_krb5.so ...

Это изменило мое sudo с 30 до 0, как и в ответе Халсафара.

— dcmorse
источник

0

На солярисе 10 sudo висела около 30 секунд. С помощью truss я наконец-то смог определить, что оно зависло от команды quota, которая висела на монтировании NFS. Размонтирование общего ресурса NFS исключило зависание. Пока не определились, что не так с акцией.

— otislafayette
источник

0

В Fedora 30 Snapd приводит к очень медленной работе sudo, su и т. Д., А также к другим проблемам, связанным с сеансами.

Удаление snapd, если вы работаете в Fedora, является рекомендуемой альтернативой.

— notcarlsatan
источник