Perché sudo sta impiegando troppo tempo?

13

Recentemente ho aggiornato a MacOS Sierra 10.12.4 Beta (16E144f) e potrebbe essere ciò che sta causando sudoa ritardare fino a 10 minuti in quanto è il recente cambiamento mi ricordo più da quando si è verificato questo problema. Non ho mai dovuto aspettare così tanto tempo per un programma di base e qualcosa è chiaramente sbagliato. Il comando alla fine riesce, ma dopo aver aspettato troppo a lungo.

Ho usato questa domanda come riferimento. Finora, ho provato ad aggiungere il mio nome host alla fine della 127.0.0.1riga /etc/hostse. Ho controllato /etc/resolv.confe avevo alcune voci extra da quando ero su una rete che aveva bisogno di voci DNS manuali, ma le ho rimosse e non c'era alcuna differenza. Ho usato il networksetup -setdnsserverscomando per ripristinare i valori originali. Internet funziona ancora bene ma è ancora molto lento sudo.

Ho provato il logger 'test'comando pensando che sarebbe scrivere /var/log/system.log, ma sembra totalmente cancellato il file anche se è stato presto fatto di nuovo.

Speravo di usare il stracecomando per vedere cosa stava succedendo mentre era in sudoesecuzione ma quel comando non è disponibile su OS X. Qualcuno ha mai incontrato questo problema su questo sistema operativo prima?

/var/log/system.log contiene i seguenti messaggi che potrebbero essere rilevanti. Ancora una volta il comando alla fine riesce normalmente:

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

Qualsiasi aiuto sarebbe apprezzato.

— Spencer Williams
fonte

Importa quale comando esegui sudo? In che modo i timestamp nel registro sono correlati alla tua azione di esecuzione di sudo e di esecuzione su sudo? Vedo opendirectoryd lì dentro, lavori con un account locale o un account di rete? Cosa succede se si cambia utente (o ne si imposta uno nuovo a livello locale), anche sudo è lento?

— Nohillside

Sto eseguendo la stessa beta e sudo è veloce come sempre in realtà.

— Nohillside

1

@patrix Ah ok. Sì, molto bene potrebbe essere qualcos'altro. Sì, succede indipendentemente dal comando che utilizzo con sudo, il ritardo è coerente. Fondamentalmente, il comando inizia attorno a quella riga di registro com.apple.quicklooke alla fine termina alla fine, quindi in quell'esempio sono stati circa 8 minuti con tutti quei messaggi in mezzo. Il messaggio opendirectoryd sembra apparire ogni volta che viene eseguito sudo lsnella mia home directory locale. In questo momento sto lavorando solo con le cartelle locali. Ho solo un utente su questo computer, anche se riesco a vedere cosa succede con un nuovo account ...

— Spencer Williams

@patrix Ho appena creato un altro utente con privilegi di amministratore. Purtroppo, quell'account sta avendo lo stesso problema.

— Spencer Williams,

11

La risposta di ErikMH mi ha dato l'idea di provare prima a ripristinare il file sudoers, senza ripristinare / aggiornare nuovamente l'intero sistema. Quindi in breve:

Esegui questo per ottenere una shell di root: sudo -s
Fai una copia di /private/etc/sudoers
Correre: cp /private/etc/sudoers\~orig /private/etc/sudoers
Correggi le autorizzazioni eseguendo: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
Sposta tutti i file /private/etc/sudoers.d/lontano da lì
Prova sudoin un altro terminale
Non dimenticare di uscire da questa shell per impedire l'esecuzione inavvertita di comandi come root quando non intendi farlo

Ora la corsa sudodovrebbe funzionare di nuovo.

Il passaggio successivo consiste nel verificare le differenze tra il vecchio file sudoers (copiato nel passaggio 2) e quello corrente e aggiungere le modifiche passo dopo passo a /private/etc/sudoerso /private/etc/sudoers.d/, ogni volta che si esegue un comando utilizzando sudoper verificare se la modifica lo interrompe.

Nel mio caso, avevo specificato un gruppo inesistente nel file sudoers. La correzione ha risolto il problema.

— Cedric Dubois
fonte

lavorato su macOS 10.13!

— Nisba,

Ha funzionato anche per me (OSX 10.13). Aveva anche lo stesso problema: gruppo inesistente nel file sudoer.

— Petr Cibulka,

Hmm ... Non ricordo di aver cambiato il file sudoers sulla macchina in cui ho avuto questo problema, ma vorrei aver provato quello che suggerisci invece di ripristinare il mio sistema.

— Spencer Williams,

Sono andato avanti e ho accettato la tua risposta perché sembra che le persone stiano confermando che aiuta, e spero di averlo provato prima, né in generale consiglio di ripristinare l'intero sistema.

— Spencer Williams,

2

Ciò può verificarsi durante l'aggiornamento a 10.12.4 se hai mai modificato il file / private / etc / sudoers.

La soluzione più semplice è:

Torna a una versione precedente del sistema (cloni sempre il tuo sistema prima dell'aggiornamento, giusto?)
Elimina / private / etc / sudoers
Copia / private / etc / sudoers ~ orig in sudoers
Ripristina la proprietà dei sudoer su system / root - sola lettura
Aggiorna il sistema a 10.12.4

— ErikMH
fonte

"Ciò può verificarsi durante l'aggiornamento a 10.12.4 se hai mai modificato il file / private / etc / sudoers." Sappiamo cosa lo sta causando?

— Wowfunhappy,

1

Vorrei poter aver trovato la causa effettiva di questo, ma ho potuto risolvere il problema solo dopo aver ripristinato il software di sistema. In precedenza ero nella beta pubblica di macOS Sierra ma ora sono la principale.

Sto caricando lentamente tutti i miei programmi e noterò se riscontro sudonuovamente un ritardo .

— Spencer Williams
fonte

0

Ho /etc/sudoers.d/rimosso un file . Voila - sudoè di nuovo veloce.

— vidstige
fonte