Warum dauert die Ausführung des sudo-Befehls lange?

Ich habe in den letzten Monaten Linux (Fedora 10, dann 11) aufgegriffen (und es immens genossen - es ist, als würde man immer wieder Computer entdecken, so viele Dinge, die man lernen muss).

Ich habe meinen Benutzer wie unten gezeigt in die letzte Zeile der Datei / etc / sudoers eingefügt, damit ich beim Ausführen des Befehls sudo nicht nach meinem Kennwort gefragt werde:

MyUserName ALL = (ALL) NOPASSWD: ALL

Jedes Mal, wenn ich einen Befehl mit sudo ausführe, wird vor dem eigentlichen Ausführen der Aufgabe eine merkliche Zeitspanne angehalten (~ 10 Sekunden). Warum könnte das so sein und wie könnte ich das beheben? Ich verwende Sudo Version 1.7.1 auf Fedora 11 x86 64.

Ich habe diese Frage auf SO gestellt und sie wurde hierher verschoben. Das heißt, ich kann die Frage nicht mehr bearbeiten, als ob sie mir gehört, oder als ob ich die richtige Antwort akzeptiere. Dies stellte sich jedoch als der wahre Grund heraus, warum und wie man sie löst:

Gefunden hier Benutzer "rohandhruva" gibt dort die richtige Antwort:

Dies geschieht, wenn Sie den Hostnamen während des Installationsvorgangs ändern.

Bearbeiten Sie die Datei / etc / hosts, um das Problem zu beheben

127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 <ADD_YOURS_HERE> 
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 <ADD_YOURS_HERE>

Überprüfen Sie, ob Ihr Syslog-Daemon ordnungsgemäß funktioniert. Dies verursachte das Problem für mich.

Führen Sie den folgenden Befehl aus

logger 'Hello world'

1. Kommt der Befehl innerhalb einer angemessenen Zeit zurück?

2. Erscheint "Hallo Welt" in /var/log/syslog?

Ist dies nicht der Fall, ist der Syslog-Daemon abgestürzt. Ein Neustart sollte das Problem beheben.

Ist es eine der Dateien / Verzeichnisse, die auf einem Netzwerk-Mount gelesen werden müssen, oder löst es irgendwie das Lesen von einem langsamen USB-Gerät aus? Versuchen Sie es mit Strace und sehen Sie, wo es langsam ist. Wenn es zu schnell geht, tue es

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

Jede Zeile beginnt mit der Zeit, die seit der Eingabe des vorherigen Systemaufrufs vergangen ist.

(Das anfängliche Sudo scheint notwendig zu sein; ich weiß nicht, wie sehr das die Ergebnisse stören wird.)

Ich habe kürzlich festgestellt, dass ich das gleiche Problem hatte. Es hatte keine Sudo-Verzögerung und dann plötzlich eine Verzögerung von etwa 10-20 Sekunden gegeben. Ich habe das spezifische Problem folgendermaßen ermittelt:

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

Wie Sie selbst:

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

Und dann finden Sie, wo die Systemaufrufe hängen.

In MEINEM Fall stellte ich fest, dass es an einer DNS-Übersetzung hing, anscheinend war einer der DNSen in meiner Liste /etc/resolv.confsehr geschäftig oder schlecht. Also habe ich die Auflösungsreihenfolge geändert und die Dinge funktionierten schnell wieder.

Ich bin mir bei Fedora nicht sicher, aber ich habe andere Systeme verwendet, auf denen sudo überprüft, woher Sie angemeldet sind. Wenn Ihr DNS nicht richtig eingerichtet ist, kann es eine Ewigkeit dauern, bis das Zeitlimit abgelaufen ist. Dies ist auch zu sehen, wenn SSH in die Maschine eingeht - es dauert eine Ewigkeit, bis eine Eingabeaufforderung vorliegt.

Ich hatte das gleiche Problem, ich überprüfte /var/log/auth.log und Syslog auf Fehler. Es stellte sich heraus, dass mein LDAP-Server nicht erreichbar war und alles verlangsamte.

Ich habe keine LDAP-basierte Authentifizierung mehr verwendet und daher alle "ldap" -Verweise aus /etc/nsswitch.conf entfernt

Seitdem funktioniert alles wieder wie ein Zauber.

In einigen Fällen wurde festgestellt, dass der Hostname (der in /etc/sysconfig/ network konfiguriert wurde ) nicht in der /etc/hostsDatei vorhanden ist. Nach dem Hinzufügen der oben genannten Datei wird die Datei sofort geöffnet.

Ich hatte ein ähnliches Problem. Ich habe es behoben, indem ich sowohl den Hostnamen (z. B. mybox) als auch die vollständige Ausgabe des Befehls hostname (mybox.meinedomain.com) eingegeben habe. Dies machte es richtig klar. Ging von 2 Minuten, um / etc / hosts zu öffnen und sofort darauf zuzugreifen.

SELinux-Fall

Wenn der gleiche sudo-Befehl nur in einem Daemon langsam und in der Befehlszeile schnell ist, wird er höchstwahrscheinlich von SELinux verursacht . (SELinux = NSA Security-Enhanced Linux-Kernelmodul, standardmäßig in Fedora aktiviert.)

Ein typischer Fall ist ein http-Server und ein spezielles Skript für die Serververwaltung, eingeschränkt in sudoers:

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

In diesem Fall wird normalerweise nichts über SELinux im Überwachungsprotokoll gemeldet ausearch -m avc -ts today, aber das Skript wird schnell ausgeführt, wenn die Erzwingung durch vorübergehend deaktiviert wird setenforce 0. (und dann wieder aktivieren durch setenforce 1)

Die einzigen relevanten Meldungen im Systemprotokoll (journalcrl) sind nach der Verzögerung von 25 Sekunden:

... sudo [...] pam_systemd (sudo: session): Sitzung konnte nicht erstellt werden: Keine Antwort erhalten. Mögliche Ursachen sind: Die Remoteanwendung hat keine Antwort gesendet, die Nachrichtenbussicherheitsrichtlinie hat die Antwort blockiert, das Antwortzeitlimit ist abgelaufen oder die Netzwerkverbindung wurde unterbrochen.
... sudo [...]: pam_unix (sudo: session): Sitzung für Benutzer root geöffnet von (uid = 0)

Die Protokollierung aller stillen "Dont-Audit" SElinux-Nachrichten kann von aktiviert semodule -DBund von wieder deaktiviert werden semodule -B.
(Ich hoffe, dass ich bald ein SELinux-Richtlinienmodul für diesen Fall hier schreibe oder eine Methode aus dieser Antwort verwenden kann.)

Ausgehend von der Beispieldatei sudoers, die ich habe, glaube ich, dass nach dem NOPASSWD:Bit ein Leerzeichen eingefügt werden soll.

Überprüfen Sie Ihre Datei / etc / hosts und stellen Sie sicher, dass Sie einen Eintrag für 127.0.0.1 haben

( Quelle )

Stellen Sie nach dem Beheben von Hostproblemen sicher, dass Sie alle fehlerhaften DNS-Caches löschen, wenn Sie eine DNS-Caching-Anwendung wie nscd ausführen:

/etc/init.d/nscd force-reload

Für mich war es krb5-user / config / locales, das installiert wurde. Ich habe dies durch Untersuchen von /var/log/auth.log bemerkt. Verwenden Sie apt-get remove, um diese Pakete zu deinstallieren. Entfernen Sie diese Pakete nicht, wenn Sie sich auf einem Computer befinden, der offensichtlich Kerberos (pam_krb5) benötigt.

Verwenden Sie LDAP zur Authentifizierung?

Wenn ja, möchten Sie wahrscheinlich bind policy soft verwenden. In /etc/ldap/ldap.conf (oder /etc/ldap.conf):

bind_policy soft

Klingt so, als hätten Sie eine Art Timeout in Ihrer Authentifizierungskette. Überprüfen Sie, wie sudo versucht, sich zu authentifizieren, und achten Sie auf Engpässe.

Systemd Fall

Für mich hatte mein System keinen Speicher mehr und viele Prozesse stürzten ab. Mein System basiert auf systemd und etwas ist dort abgestürzt. Es fällt mir schwer, mich an alles zu erinnern, was ich getan habe, aber:

• systemctl status <any.service> würde aussetzen
• Ich konnte nicht sudo reboot(systembasiert)

Lösung

Ein Neustart hat mein Problem behoben, aber für mich war es nur ein Bandaid. Sie müssen immer noch herausfinden, warum Ihnen der Speicher ausgeht oder Sie abgestürzt sind.