Warum dauert sudo viel zu lange?

Ich habe kürzlich auf macOS Sierra 10.12.4 Beta (16E144f) aktualisiert und es könnte die sudoVerzögerung von bis zu 10 Minuten verursachen, da dies die letzte Änderung ist, an die ich mich erinnere, seit dieses Problem aufgetreten ist. Ich musste noch nie so lange auf ein Grundprogramm warten und da stimmt eindeutig etwas nicht. Der Befehl ist schließlich erfolgreich, aber nachdem er viel zu lange gewartet hat.

Ich habe diese Frage als Referenz verwendet. Bisher habe ich versucht, meinen Hostnamen am Ende der 127.0.0.1Zeile in /etc/hostssowie hinzuzufügen. Ich habe nachgesehen /etc/resolv.confund hatte einige zusätzliche Einträge aus der Zeit, als ich in einem Netzwerk war, das manuelle DNS-Einträge benötigte, aber ich habe sie entfernt und es gab keinen Unterschied. Ich habe den networksetup -setdnsserversBefehl verwendet, um die ursprünglichen Werte wiederherzustellen. Internet funktioniert immer noch gut, aber immer noch sehr langsam sudo.

Ich habe den logger 'test'Befehl ausprobiert und dachte, er würde in schreiben /var/log/system.log, aber es sieht so aus, als ob er diese Datei vollständig gelöscht hat, obwohl sie bald neu erstellt wurde.

Ich hatte gehofft, den straceBefehl zu verwenden, um zu sehen, was während der Ausführung passiert sudo, aber dieser Befehl ist unter OS X nicht verfügbar. Ist jemandem zuvor dieses Problem auf diesem Betriebssystem begegnet?

/var/log/system.log hat die folgenden Meldungen, die relevant sein können. Auch hier gelingt der Befehl schließlich wie gewohnt:

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

Jede Hilfe wäre willkommen.

Spielt es eine Rolle, welchen Befehl Sie über sudo ausführen? Wie beziehen sich die Zeitstempel im Protokoll auf Ihre Aktion zum Ausführen von sudo und zum Durchlaufen von sudo? Ich sehe dort opendirectoryd, arbeitest du mit einem lokalen Konto oder einem Netzwerkkonto? Was passiert, wenn Sie den Benutzer wechseln (oder lokal einen neuen einrichten), ist sudo auch dort langsam?
Ich führe die gleiche Beta aus und sudo ist eigentlich schnell wie immer.
@patrix Ah okay. Ja, es könnte sehr gut etwas anderes sein. Ja, es passiert, egal welchen Befehl ich mit sudo verwende, die Verzögerung ist konsistent. Grundsätzlich beginnt der Befehl um diese Protokollzeile herum com.apple.quicklookund endet schließlich am Ende, also waren es in diesem Beispiel ungefähr 8 Minuten mit all diesen Nachrichten dazwischen. Die Opendirectoryd-Meldung scheint immer dann aufzutreten, wenn sie endlich sudo lsin meinem lokalen Home-Verzeichnis ausgeführt wird. Im Moment arbeite ich nur mit lokalen Ordnern. Ich habe nur einen Benutzer auf diesem Computer, obwohl ich sehen kann, was mit einem neuen Konto passiert ...
@patrix Ich habe gerade einen anderen Benutzer mit Administratorrechten erstellt. Leider hat dieses Konto genau das gleiche Problem.

Antworten (4)

Die Antwort von ErikMH brachte mich auf die Idee, zunächst nur zu versuchen, die Sudoers-Datei zurückzusetzen, ohne mein gesamtes System erneut zurückzusetzen/zu aktualisieren. Also kurz:

  1. Führen Sie dies aus, um eine Root-Shell zu erhalten:sudo -s
  2. Machen Sie eine Kopie von/private/etc/sudoers
  3. Laufen:cp /private/etc/sudoers\~orig /private/etc/sudoers
  4. Beheben Sie die Berechtigungen, indem Sie Folgendes ausführen:chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
  5. Verschieben Sie alle Dateien /private/etc/sudoers.d/von dort weg
  6. Testen Sie sudoin einem anderen Terminal
  7. Vergessen Sie nicht, diese Shell zu verlassen, um zu verhindern, dass versehentlich Befehle als root ausgeführt werden, wenn Sie dies nicht wollen

Jetzt sudosollte das Laufen wieder funktionieren.

Der nächste Schritt besteht darin, die Unterschiede zwischen der alten sudoers-Datei (die Sie in Schritt 2 wegkopiert haben) und der aktuellen zu überprüfen und diese Änderungen Schritt für Schritt wieder zu /private/etc/sudoersoder hinzuzufügen /private/etc/sudoers.d/, wobei jedes Mal ein Befehl ausgeführt wird, der verwendet wird sudo, um zu prüfen, ob die Änderung sie beschädigt.

In meinem Fall hatte ich in der sudoers-Datei eine nicht vorhandene Gruppe angegeben. Durch die Korrektur wurde mein Problem behoben.

funktionierte auf macOS 10.13!
Hat auch bei mir funktioniert (OSX 10.13). Hatte auch das gleiche Problem - nicht vorhandene Gruppe in der Sudoer-Datei.
Hmm ... Ich kann mich nicht erinnern, die sudoers-Datei auf dem Computer geändert zu haben, auf dem ich dieses Problem hatte, aber ich wünschte, ich hätte versucht, was Sie vorschlagen, anstatt mein System wiederherzustellen.
Ich habe Ihre Antwort akzeptiert, weil es so aussieht, als würden die Leute bestätigen, dass es hilft, und ich wünschte, ich hätte dies zuerst versucht, und ich empfehle auch nicht, Ihr gesamtes System wiederherzustellen.
Bei Schritt 3 erhalte ich eine Fehlermeldungcp: /private/etc/sudoers~orig: No such file or directory

Dies kann beim Upgrade auf 10.12.4 auftreten, wenn Sie jemals die Datei /private/etc/sudoers bearbeitet haben.

Einfachste Lösung ist:

  1. Wechseln Sie zu einer früheren Version des Systems zurück (Sie klonen Ihr System immer vor dem Update, richtig?)
  2. Löschen Sie /private/etc/sudoers
  3. Kopieren Sie /private/etc/sudoers~orig nach sudoers
  4. Setzen Sie den Besitz von sudoern auf system/root zurück – schreibgeschützt
  5. Aktualisieren Sie das System auf 10.12.4
"Dies kann beim Upgrade auf 10.12.4 auftreten, wenn Sie jemals die Datei /private/etc/sudoers bearbeitet haben." Wissen wir, was es tatsächlich verursacht?

Ich wünschte, ich hätte die eigentliche Ursache dafür finden können, aber ich konnte das Problem erst lösen, nachdem ich die Systemsoftware wiederhergestellt hatte. Ich war zuvor in der Public Beta von macOS Sierra, aber jetzt bin ich in der Hauptversion.

Ich lade langsam alle meine Programme zurück und werde es vermerken, wenn ich sudowieder eine Verzögerung erlebe.

Ich hatte eine Datei darin /etc/sudoers.d/, die ich entfernt habe. Voila - sudoist wieder schnell.