Dlaczego sudo trwa zbyt długo?

13

Niedawno zaktualizowałem system macOS Sierra 10.12.4 Beta (16E144f) i może to powodować sudoopóźnienie do 10 minut, ponieważ jest to ostatnia zmiana, którą pamiętam od czasu wystąpienia tego problemu. Nigdy nie musiałem tak długo czekać na podstawowy program i coś jest wyraźnie nie tak. Komenda ostatecznie się udaje, ale po długim oczekiwaniu.

Użyłem tego pytania jako odniesienia. Do tej pory próbowałem dodać moją nazwę hosta na końcu 127.0.0.1linii, /etc/hostsjak również. Sprawdziłem /etc/resolv.confi miałem kilka dodatkowych wpisów, kiedy byłem w sieci, która wymagała ręcznych wpisów DNS, ale usunąłem je i nie było różnicy. Użyłem networksetup -setdnsserverspolecenia, aby przywrócić oryginalne wartości. Internet nadal działa dobrze, ale nadal bardzo wolno sudo.

Próbowałem tego logger 'test'polecenia, myśląc, że napisze /var/log/system.log, ale wygląda na to, że całkowicie usunął ten plik, chociaż wkrótce został ponownie utworzony.

Miałem nadzieję, że użyję stracepolecenia, aby zobaczyć, co się dzieje podczas sudouruchamiania, ale to polecenie nie jest dostępne w systemie OS X. Czy ktoś wcześniej napotkał ten problem w tym systemie operacyjnym?

/var/log/system.log zawiera następujące komunikaty, które mogą być istotne. Ponownie polecenie ostatecznie kończy się normalnie:

Feb  1 00:07:39 mycomputer com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Feb  1 00:07:56 mycomputer com.apple.xpc.launchd[1] (com.apple.quicklook[2355]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
Feb  1 00:08:16 mycomputer System Preferences[1886]: I can not do what i want
Feb  1 00:11:23 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2335]): Service exited with abnormal code: 70
Feb  1 00:12:07 mycomputer syslogd[54]: ASL Sender Statistics
Feb  1 00:16:35 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2395]): Service exited with abnormal code: 70

Każda pomoc będzie mile widziana.

— Spencer Williams
źródło

Czy ma znaczenie, które polecenie wykonujesz przez sudo? W jaki sposób znaczniki czasu w dzienniku odnoszą się do twojej akcji wykonywania sudo i uruchamiania sudo? Widzę tam opendirectoryd, czy pracujesz z kontem lokalnym czy kontem sieciowym? Co się stanie, jeśli zmienisz użytkowników (lub skonfigurujesz nowego lokalnie), czy sudo też tam działa wolno?

— nohillside

Korzystam z tej samej wersji beta, a sudo działa szybko jak zawsze.

— nohillside

1

@patrix Ah dobrze. Tak, może to być coś innego. Tak, zdarza się bez względu na to, jakiego polecenia użyję w sudo, opóźnienie jest spójne. Zasadniczo polecenie zaczyna się wokół tej linii dziennika com.apple.quicklooki na końcu kończy się na końcu, więc w tym przykładzie było to około 8 minut ze wszystkimi komunikatami pomiędzy nimi. Komunikat opendirectoryd wydaje się pojawiać, ilekroć w końcu zostanie uruchomiony sudo lsw moim lokalnym katalogu domowym. Obecnie pracuję tylko z folderami lokalnymi. Mam tylko jednego użytkownika na tym komputerze, chociaż widzę, co dzieje się z nowym kontem ...

— Spencer Williams

@patrix Właśnie utworzyłem innego użytkownika z uprawnieniami administratora. Niestety konto ma ten sam problem.

— Spencer Williams

11

Odpowiedź ErikMH podsunęła mi pomysł, aby najpierw spróbować przywrócić plik sudoers, bez ponownego przywracania / aktualizacji całego systemu. W skrócie:

Uruchom to, aby uzyskać powłokę roota: sudo -s
Zrób kopię /private/etc/sudoers
Biegać: cp /private/etc/sudoers\~orig /private/etc/sudoers
Napraw uprawnienia, uruchamiając: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
Przenieś dowolne pliki /private/etc/sudoers.d/stamtąd
Przetestuj sudow innym terminalu
Nie zapomnij wyjść z tej powłoki, aby zapobiec niezamierzonemu uruchomieniu poleceń jako root, gdy nie masz na to ochoty

Teraz bieganie sudopowinno znów działać.

Następnym krokiem jest sprawdzenie różnic między starym plikiem sudoers (skopiowanym w kroku 2) a bieżącym i dodanie tych zmian krok po kroku z powrotem do /private/etc/sudoerslub /private/etc/sudoers.d/, za każdym razem uruchamiając polecenie za pomocą, sudoaby sprawdzić, czy zmiana go psuje.

W moim przypadku podałem nieistniejącą grupę w pliku sudoers. Poprawienie tego rozwiązało mój problem.

— Cedric Dubois
źródło

działał na macOS 10.13!

— Nisba

Pracowałem również dla mnie (OSX 10.13). Miał również ten sam problem - nieistniejąca grupa w pliku sudoer.

— Petr Cibulka,

Hmm ... Nie pamiętam zmiany pliku sudoers na komputerze, na którym miałem ten problem, ale chciałbym spróbować tego, co sugerujesz, zamiast przywracania mojego systemu.

— Spencer Williams

Poszedłem dalej i zaakceptowałem twoją odpowiedź, ponieważ wygląda na to, że ludzie potwierdzają, że to pomaga, i na pewno żałuję, że nie wypróbowałem tego wcześniej, ani ogólnie nie zalecam przywracania całego systemu.

— Spencer Williams

2

Może się to zdarzyć podczas aktualizacji do 10.12.4, jeśli kiedykolwiek edytowałeś plik / private / etc / sudoers.

Najłatwiejszym rozwiązaniem jest:

Wróć do poprzedniej wersji systemu (zawsze klonujesz system przed aktualizacją, prawda?)
Usuń / private / etc / sudoers
Skopiuj / private / etc / sudoers ~ orig do sudoers
Zresetuj własność sudoers do systemu / root - tylko do odczytu
Zaktualizuj system do 10.12.4

— ErikMH
źródło

„Może się to zdarzyć podczas aktualizacji do 10.12.4, jeśli kiedykolwiek edytowałeś plik / private / etc / sudoers.” Czy wiemy, co tak naprawdę powoduje?

— Wowfunhappy

1

Chciałbym móc znaleźć rzeczywistą przyczynę tego problemu, ale mogłem rozwiązać problem dopiero po przywróceniu oprogramowania systemowego. Wcześniej byłem na publicznej wersji beta macOS Sierra, ale teraz jestem na głównej.

Powoli ładuję z powrotem wszystkie moje programy i zauważę, czy sudoznowu wystąpią opóźnienia .

— Spencer Williams
źródło

0

Miałem plik, /etc/sudoers.d/który usunąłem. Voila - sudoznów jest szybki.

— vidstige
źródło