Za każdym razem, gdy używam sudo, zawiesza się przed ukończeniem

Niezależnie od tego, czy pojawi się monit o hasło, czy nie, zawiesza się między zaakceptowaniem uwierzytelnienia a wykonaniem tego, o co prosiłem. Innymi słowy sudo lszawiesi się na około 60 sekund.

Jestem zdezorientowany, co może być przyczyną tego. To jest na Centos 5, a ja spojrzałem selinuxi ustawiłem zarówno na wyłączony, jak i włączony, ale wydaje się, że nie ma to żadnego wpływu.

Od odpowiedzi @ TheAndruu na to pytanie:

Dzieje się tak, jeśli zmienisz nazwę hosta podczas procesu instalacji. Aby rozwiązać problem, edytuj plik / 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]

Miałem dokładnie ten sam problem na Fedorze 11 i to rozwiązało.

Czasami, gdy domyślna trasa nie jest ustawiona, polecenia takie jak sudo się zawieszają.

Spróbuj netstat -rsprawdzić, czy trasa jest ustawiona poprawnie.

Czy ta maszyna otrzymuje hasła z lokalnego pliku / etc / passwd lub czegoś takiego jak ldap?

Jedyną rzeczą, którą możesz chcieć sprawdzić, jest plik /etc/resolv.conf, aby upewnić się, że masz tam odpowiedni wpis dns. W przeszłości widziałem, gdzie może to powodować opóźnienia.

Powinieneś sprawdzić trzy rzeczy. 1. / etc / nazwa hosta 2. / etc / hosts 3. /etc/resolv.conf

Odkryłem, że moja nazwa hosta jest poprawna, że ​​plik hosts jest niepoprawny, a ponadto resolv.conf wymaga aktualizacji.

Dla mnie instalowano krb5-user / config. Zauważyłem to, sprawdzając /var/log/auth.log i widząc próby pam_krb5 przed pam_unix. Naprawiono go za pomocą apt-get remove w celu odinstalowania tych pakietów. Nie usuwaj tych pakietów, jeśli oczywiście korzystasz z komputera Kerberos (pam_krb5). Mój sudo zawiesił się z konsekwentnych lat 30-tych do 0-tych.

Jest to zasugerował w Halsafar „s odpowiedź , mam Kerberos włączone mojej pracy VPN, ale jest bezużyteczny, gdy jestem przy nim, więc zmieniłem kolejność moduł uwierzytelniania w /etc/pam.d/common-authcelu wykorzystania pam_unixprzed pam_krb5:

Przed:

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

Po:

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

To zmieniło moje sudo z 30 na 0, jak to zrobiłem w odpowiedzi Halsafara.

Na Solarisie 10 sudo wisiał przez około 30 sekund. Z pomocą kratownicy w końcu udało mi się ustalić, że wisiał na komendzie quota, która wisiała na wierzchowcu NFS. Odmontowanie udziału NFS wyeliminowało zawieszenie. Nie ustaliłem jeszcze, co jest nie tak z udziałem.

W Fedorze 30 Snapd powoduje, że sudo, su itp. Stają się bardzo wolne, a także inne problemy związane z sesją.

Odinstalowanie snapd, jeśli jesteś w Fedorze, jest zalecaną alternatywą.