Perché l'esecuzione del comando sudo richiede molto tempo?

Ho raccolto Linux (Fedora 10, quindi 11) negli ultimi mesi (e mi sono divertito immensamente - è come scoprire di nuovo computer, così tante cose da imparare).

Ho aggiunto il mio utente all'ultima riga del file / etc / sudoers come mostrato di seguito, in modo che non mi venga chiesta la password quando eseguo il comando sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Ora ogni volta che eseguo un comando usando sudo, fa una pausa notevole prima di eseguire effettivamente l'attività (~ 10 secondi). Perché questo potrebbe essere e come potrei risolverlo? Sto eseguendo la versione 1.7.1 di Sudo su Fedora 11 x86 64.

Ho posto questa domanda su SO ed è stata spostata qui. Detto questo, non ho più la possibilità di modificare la domanda come se la possedessi o di accettare la risposta corretta, ma questa si è rivelata la vera ragione per cui e come risolverla:

Trovato qui L' utente "rohandhruva" lì dà la risposta giusta:

Ciò accade se si modifica il nome host durante il processo di installazione.

Per risolvere il problema, modificare il file / 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>

Verifica che il tuo demone syslog funzioni correttamente; questo ha causato il problema per me.

Esegui il seguente comando

logger 'Hello world'

1. Il comando ritorna entro un ragionevole lasso di tempo?

2. "Hello world" appare /var/log/syslog?

In caso contrario, il daemon syslog si è arrestato in modo anomalo. Il riavvio dovrebbe risolvere il problema.

È uno dei file / directory che deve leggere su un mount in rete o in qualche modo sta innescando la lettura da un dispositivo USB lento? Prova lo strace e vedi dove è lento; se va troppo veloce, fallo

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

Ogni riga inizierà con il tempo impiegato dall'entrata nella precedente scala di comando.

(Il sudo iniziale sembra essere necessario; non so quanto ciò perturberà i risultati.)

Recentemente ho scoperto di avere lo stesso problema. Non c'era stato alcun ritardo sudo e poi all'improvviso, un ritardo di circa 10-20 secondi. Ho determinato il problema specifico utilizzando:

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

Come te stesso:

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

E poi trova dove sono sospese le chiamate di sistema.

Nel mio caso, ho scoperto che era appeso a una traduzione DNS, apparentemente uno dei DNS nella mia lista /etc/resolv.confera molto pieno o andato male. Quindi ho cambiato l'ordine di risoluzione e le cose di poof hanno funzionato di nuovo rapidamente.

Non sono sicuro di Fedora, ma ho usato altri sistemi in cui sudo controllava da dove vieni collegato, che se il tuo DNS non è impostato bene può richiedere anni per il timeout. Questo può essere visto anche quando SSH si collega alla macchina: ci vogliono anni per trovare un prompt.

Ho lo stesso problema, ho controllato /var/log/auth.log e syslog per errori. Risulta che il mio server LDAP non è stato raggiunto e ha rallentato tutto.

Non ho più usato l'autenticazione basata su LDAP, quindi ho rimosso tutti i riferimenti "ldap" da /etc/nsswitch.conf

Da allora tutto funziona di nuovo come un incantesimo.

In tal caso, viene rilevato che il nome host (configurato in /etc/sysconfig/ network) non esiste nel /etc/hostsfile; quindi dopo aver aggiunto il file sopra menzionato, il file si apre prontamente.

Ho avuto un problema simile, l'ho risolto inserendo sia il nome host (ad esempio mybox) sia l'output completo del comando hostname (mybox.mydomain.com). Questo l'ha chiarito. Sono passati da 2 minuti ad aprire / etc / hosts per l'accesso istantaneo.

Caso SELinux

Se lo stesso comando sudo è lento solo in un demone e veloce sulla riga di comando, è probabilmente causato da SELinux . (SELinux = modulo kernel NSA Security-Enhanced Linux, abilitato in Fedora di default.)

Un caso tipico è un server http e uno script speciale per la gestione del server, limitato a sudoers:

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

È tipico in questo caso che nel registro di controllo non sia riportato nulla su SELinux ausearch -m avc -ts today, ma lo script procede rapidamente se disabilitiamo temporaneamente l'applicazione setenforce 0. (e quindi indietro abilitato da setenforce 1)

Gli unici messaggi rilevanti nel registro di sistema (journalcrl) sono questi dopo il ritardo di 25 secondi:

... sudo [...] pam_systemd (sudo: session): impossibile creare la sessione: non ha ricevuto risposta. Le possibili cause includono: l'applicazione remota non ha inviato una risposta, la politica di sicurezza del bus messaggi ha bloccato la risposta, il timeout di risposta è scaduto o la connessione di rete è stata interrotta.
... sudo [...]: pam_unix (sudo: session): sessione aperta per l'utente root da (uid = 0)

La registrazione di tutti i messaggi SElinux "dont-audit" silenziati può essere abilitata semodule -DBe disabilitata di nuovo da semodule -B.
(Spero di scrivere presto un modulo di politica SELinux presto per questo caso qui o un metodo da questa risposta può essere utilizzato.)

Guardando il sudoersfile di esempio che ho, credo che dovrebbe esserci uno spazio dopo il NOPASSWD:bit.

Controlla il tuo file / etc / hosts e assicurati di avere una voce per 127.0.0.1

( fonte )

Dopo aver risolto eventuali problemi dell'host, assicurati di cancellare qualsiasi cache DNS non valida se stai eseguendo un'applicazione di cache DNS come nscd:

/etc/init.d/nscd force-reload

Per me era krb5-user / config / locales da installare. Ho notato questo esaminando /var/log/auth.log. Utilizzando apt-get remove per disinstallare quei pacchetti, è stato risolto. Non rimuovere quei pacchetti se ci si trova su un computer che richiede Kerberos (pam_krb5) ovviamente.

Stai usando LDAP per l'autenticazione?

In tal caso, probabilmente si desidera utilizzare la politica di associazione soft. In /etc/ldap/ldap.conf (o /etc/ldap.conf):

bind_policy soft

Sembra che tu abbia una sorta di timeout nella tua catena di autenticazione. Controlla come sudo tenta di autenticarsi e osserva i colli di bottiglia.

Caso Systemd

Per me, il mio sistema aveva esaurito la memoria e molti processi si sono arrestati in modo anomalo. Il mio sistema si basa su systemd e qualcosa lì dentro si è bloccato. È difficile per me ricordare tutto ciò che ho fatto, ma:

• systemctl status <any.service> sarebbe scaduto
• Non potrei sudo reboot(basato su systemd)

Soluzione

Un riavvio risolto il mio problema, ma per me era solo un cerotto. Hai ancora bisogno di scoprire perché hai esaurito la memoria / si è bloccato.