it-swarm.it

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, si mette in pausa un notevole lasso di tempo 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.

88
Cuga

Ho posto questa domanda su SO e si è spostato qui. Detto questo non ho più la possibilità di modificare la domanda come se l'avessi posseduta, o anche di accettare la risposta corretta, ma questo ha girato per essere il vero motivo per cui e come risolverlo:

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>
130
Cuga

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" viene visualizzato in /var/log/syslog?

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

25
MattB

È 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.)

11
ysth

Recentemente ho scoperto di avere lo stesso problema. Non c'era stato alcun ritardo del 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 su /etc/resolv.conf era molto vivace o andato male. Quindi ho cambiato l'ordine di risoluzione e le cose di poof hanno funzionato di nuovo rapidamente.

9
mdpc

Ho lo stesso problema, ho controllato /var/log/auth.log e syslog per errori. Si scopre 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.

5
Sakuraba

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

5
Zahid Hussain

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 entra nella macchina - ci vogliono anni per trovare un Prompt.

5
Colin Coghill

Caso SELinux

Se lo stesso comando Sudo è lento solo in un demone e veloce sulla riga di comando, allora è causato da SELinux il più probabilmente. (SELinux = NSA Modulo kernel Linux ottimizzato per la sicurezza, abilitato in Fedora di default.)

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

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

È tipico in questo caso che nulla di ciò che riguarda SELinux sia riportato nel registro di controllo ausearch -m avc -ts today, ma lo script sta andando veloce se disabilitiamo temporaneamente l'applicazione di setenforce 0. (e quindi indietro abilitare da setenforce 1)

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

... Sudo [...] pam_systemd (Sudo: sessione): impossibile creare la sessione: non ho 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: sessione): sessione aperta per l'utente root da (uid = 0)

La registrazione di tutti i messaggi SElinux "dont-audit" silenziati può essere abilitata da semodule -DB e nuovamente disabilitato 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 usato.)

3
hynekcer

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 sei su un computer che richiede Kerberos (pam_krb5) ovviamente.

1
Halsafar

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

( fonte )

1
Ryan Emerle

Dopo aver risolto eventuali problemi relativi all'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
1
Roger Smith

Dall'esame del file sudoers di esempio che ho, credo che ci dovrebbe essere uno spazio dopo il NOPASSWD: po.

1

Sembra che tu abbia una sorta di timeout nella tua catena di autenticazione. Controlla come Sudo prova ad autenticare e osserva i colli di bottiglia.

0
towo

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 potevo Sudo reboot (basato su systemd)

Soluzione

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

0
Eric Fossum

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
0
jtimberman