Il primo sudoche inserisco sul mio server Ubuntu 14.04 è sempre lento. La richiesta della password viene visualizzata immediatamente, ma dopo aver premuto Invio occorrono circa 10-15 secondi prima che l'output venga stampato. Tutti i comandi sudo dopo questo vengono eseguiti immediatamente.
L'esecuzione di qualcosa del genere sudo strace -S time -c sudo echo hinon mostra nulla di utile in questo caso, poiché il sudo di sudo echo hiè già il secondo sudo ed esegue velocemente. Se passa un po 'di tempo e devo reinserire la password in una sessione in corso, è di nuovo lento.
Tutte le soluzioni che ho trovato riguardavano l'aggiunta del nome host come risoluzione per 127.0.0.1 nel /etc/hostsfile, cosa che non ho fatto nulla. su rootesegue all'istante. L'unica cosa che ricordo di aver cambiato negli ultimi giorni è la maschera di rete di una sottorete che il server sta instradando, installando samba, dnsutils e bind9. Ma nessuno di questi processi è in esecuzione e il problema rimane, nell'accesso fisico, sessioni ssh e sessioni tmux.
EDIT: nuovo approccio
Ho provato a correre sudo tcpdump -vvvi any > tcpdump.log mentre tutte le schede di rete sono disconnesse. Il registro mostra molte delle seguenti:
18:35:09.453399 IP (tos 0x0, ttl 64, id 49112, offset 0, flags [DF], proto UDP (17), length 76)
localhost.38498 > localhost.domain: [bad udp cksum 0xfe4b -> 0x1050!] 58546+ SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. (48)
18:35:09.457412 IP (tos 0x0, ttl 64, id 49113, offset 0, flags [none], proto UDP (17), length 76)
localhost.domain > localhost.38498: [bad udp cksum 0xfe4b -> 0x8fcd!] 58546 ServFail q: SRV? _kerberos._udp.KF.OURLOCALDOMAIN.DE. 0/0/0 (48)
Le stesse voci vengono visualizzate con tcp instad di udp. Ho sostituito il nome di dominio della nostra università con OURLOCALDOMAIN.
Ora penso che Kerberos potrebbe avere qualcosa a che fare con esso, ma ho eliminato /etc/krb5.conf e riavviato, ancora nessuna modifica. Mi sembra che il server tenti di convalidarsi su un server Kerberos centrale della nostra rete universitaria. So che alcuni anni prima, questo IP era registrato su un server che eseguiva samba per il nostro dipartimento. Potrebbe esserci una connessione? Ho cambiato il mio nome host con quello usato allora, nessun cambiamento nel comportamento sudo. Lmwangi suggerisce qualcosa su PAM, di cui ho poca conoscenza, quindi non so come affrontarlo. Mi sono anche ricordato di essere passato da Heimdal Kerberos a MIT Kerberos durante l'installazione di samba, perché ho avuto problemi durante l'installazione di samba. Proverò anche le idee dai commenti nei prossimi giorni, ma viaggerò per un paio di giorni, quindi potrebbe richiedere del tempo.
EDIT 2: risolto
C'era una voce di ricerca DNS nella legacy /etc/network/interfacesche incasinava tutto. Mi sento molto stupido. Ora funziona tutto.
sudo -kper rimuovere le credenziali memorizzate nella cache. Ho trovato strace -Tro sudo.log sudo echo hiutile in quanto l'ultima colonna mostra l'ora di ogni chiamata. grepper unamee socketcome antipasto.
-rdall'opzione (che potrebbe essere eventualmente rimossa). Inizia cercando le chiamate lunghe -Tdall'opzione: sono quelle entro <e >- 0,000097 sec nel tuo caso.
stracealla fine ti porterà lì, ma questo è probabilmente un problema di configurazione di livello superiore. Le pause più lunghe durante l'autenticazione sono dovute al mancato accesso ai server remoti e alla necessità di attendere un timeout. È possibile che la modifica della sottorete inserisca il server di autenticazione su una sottorete diversa da questa. sudosalva temporaneamente un record di autenticazione riuscita sotto, /varquindi questo è probabilmente il motivo per cui le successive invocazioni passano istantaneamente.
straceti consentirà di eseguirlo senza il primosudo. Potrebbe anche essere utile utilizzare l'-o <file>opzione per salvare l'output in un file per l'analisi.