Dlaczego wykonanie polecenia sudo trwa długo?

W ciągu ostatnich kilku miesięcy korzystałem z Linuksa (Fedora 10, potem 11) (i cieszę się nim niezmiernie - to tak jakby odkrywać komputery od nowa, tyle rzeczy do nauczenia się).

Dodałem mojego użytkownika do ostatniego wiersza pliku / etc / sudoers, jak pokazano poniżej, aby nie pojawiać się pytanie o hasło podczas wykonywania polecenia sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Teraz za każdym razem, gdy wykonuję polecenie za pomocą sudo, wstrzymuje on zauważalną ilość czasu przed faktycznym wykonaniem zadania (~ 10 sekund). Dlaczego tak może być i jak mogę to naprawić? Używam Sudo w wersji 1.7.1 na Fedorze 11 x86 64.

Zadałem to pytanie na SO i tutaj zostało przeniesione. To powiedziawszy, nie mam już możliwości edytowania pytania tak, jakbym był jego właścicielem, ani nawet przyjmowania poprawnej odpowiedzi, ale okazało się to prawdziwym powodem, dla którego i jak to rozwiązać:

Znaleziony tutaj Użytkownik „rohandhruva” tam daje prawidłową odpowiedź:

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>

Sprawdź, czy demon syslog działa poprawnie; to spowodowało problem dla mnie.

Uruchom następujące polecenie

logger 'Hello world'

1. Czy polecenie powraca w rozsądnym czasie?

2. Czy pojawia się „Hello world” /var/log/syslog?

Jeśli tak nie jest, demon syslog ulega awarii. Ponowne uruchomienie powinno rozwiązać problem.

Czy jeden z plików / katalogów musi odczytać na podłączeniu do sieci, czy może w jakiś sposób wyzwala odczyt z wolnego urządzenia USB? Wypróbuj śledzenie i zobacz, gdzie jest wolne; jeśli minie zbyt szybko, zrób to

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

Każda linia rozpocznie się od czasu, jaki upłynął od wejścia do poprzedniego połączenia systemowego.

(Pierwsze sudo wydaje się konieczne; nie wiem, jak bardzo to zaburzy wyniki).

Niedawno odkryłem, że mam ten sam problem. Nie było opóźnienia sudo, a potem nagle około 10-20 sekund opóźnienia. Określiłem konkretny problem za pomocą:

 1. chmod u+s /usr/sbin/strace  (as the root user)

Jak ty:

 1. sudo -K
 2. strace sudo /bin/tcsh

A następnie dowiedz się, gdzie zawieszają się połączenia systemowe.

W MOIM przypadku okazało się, że wisi on na tłumaczeniu DNS, najwyraźniej jeden z DNSenów na mojej liście /etc/resolv.confbył bardzo mętny lub zepsuł się. Zmieniłem więc kolejność rozdzielczości i poof rzeczy znów działały szybko.

Nie jestem pewien co do Fedory, ale korzystałem z innych systemów, w których sudo sprawdzałoby, skąd jesteś zalogowany, co jeśli nie skonfigurujesz DNS, może upłynąć wiele czasu. Można to również zaobserwować, gdy SSH'ing do maszyny - wymyśla monit.

Mam ten sam problem, sprawdziłem /var/log/auth.log i syslog pod kątem błędów. Okazuje się, że mój serwer LDAP nie był dostępny i wszystko spowolniło.

Nie używałem już uwierzytelniania opartego na LDAP, więc usunąłem wszystkie odwołania do „ldap” z /etc/nsswitch.conf

Od tego czasu wszystko znów działa jak urok.

W takim przypadku nazwa hosta (skonfigurowana w /etc/sysconfig/ network) nie istnieje w /etc/hostspliku; więc po dodaniu wyżej wymienionego pliku, plik zostanie natychmiast otwarty.

Miałem podobny problem, naprawiłem go, umieszczając zarówno nazwę hosta (np. Mybox), jak i pełny wynik polecenia nazwy hosta (mybox.mydomain.com). To wszystko wyjaśniło. Poszedłem z 2 minut do otwarcia / etc / hosts do natychmiastowego dostępu.

Obudowa SELinux

Jeśli to samo polecenie sudo jest powolne tylko w demonie i szybkie w linii poleceń, najprawdopodobniej jest to spowodowane przez SELinux . (SELinux = moduł jądra Linux z ulepszonymi zabezpieczeniami NSA, domyślnie włączony w Fedorze).

Typowym przypadkiem jest serwer http i specjalny skrypt do zarządzania serwerem, ograniczony w sudoers:

apache ALL=(root_or_user) NOPASSWD: /full/path/the_safe_command

W tym przypadku typowe jest to, że w dzienniku kontroli nic nie jest zgłaszane o SELinux ausearch -m avc -ts today, ale skrypt działa szybko, jeśli tymczasowo wyłączymy wymuszanie przez setenforce 0. (a następnie włącz ponownie przez setenforce 1)

Jedynymi istotnymi komunikatami w dzienniku systemowym (Journalcrl) są te z opóźnieniem 25 sekund:

... sudo [...] pam_systemd (sudo: session): Nie można utworzyć sesji: Nie otrzymano odpowiedzi. Możliwe przyczyny to: aplikacja zdalna nie wysłała odpowiedzi, polityka bezpieczeństwa szyny wiadomości zablokowała odpowiedź, upłynął limit czasu odpowiedzi lub połączenie sieciowe zostało zerwane.
... sudo [...]: pam_unix (sudo: session): sesja otwarta dla użytkownika root przez (uid = 0)

Rejestrowanie wszystkich cichych komunikatów SElinux „bez kontroli” można włączyć semodule -DBi wyłączyć ponownie przez semodule -B.
(Mam nadzieję, że wkrótce napiszę tutaj moduł zasad SELinuksa dla tego przypadku lub można użyć metody z tej odpowiedzi ).

Patrząc na przykładowy sudoersplik, który mam, sądzę, że po NOPASSWD:bicie powinna być spacja .

Sprawdź plik / etc / hosts i upewnij się, że masz wpis 127.0.0.1

( źródło )

Po naprawieniu problemów z hostem upewnij się, że wyczyściłeś złą pamięć podręczną DNS, jeśli korzystasz z aplikacji buforującej DNS, takiej jak nscd:

/etc/init.d/nscd force-reload

Dla mnie instalowano krb5-user / config / locales. Zauważyłem to, sprawdzając /var/log/auth.log. 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).

Czy używasz LDAP do uwierzytelniania?

Jeśli tak, prawdopodobnie chcesz użyć miękkiej polityki wiązania. W /etc/ldap/ldap.conf (lub /etc/ldap.conf):

bind_policy soft

Wygląda na to, że masz jakiś limit czasu w łańcuchu uwierzytelniania. Sprawdź, jak sudo próbuje się uwierzytelnić i wypatruj wąskich gardeł.

Sprawa systemowa

Dla mnie w moim systemie zabrakło pamięci i wiele procesów uległo awarii. Mój system opiera się na systemd i coś się tam zawiesiło. Trudno mi zapamiętać wszystko, co zrobiłem, ale:

• systemctl status <any.service> przekroczyłby limit czasu
• Nie mogłem sudo reboot(na podstawie systemowej)

Rozwiązanie

Ponowne uruchomienie naprawiło mój problem, ale dla mnie była to tylko bandaid. Nadal musisz dowiedzieć się, dlaczego zabrakło Ci pamięci / uległa awarii.