¿Por qué el sudo tarda demasiado?

13

Recientemente actualicé a macOS Sierra 10.12.4 Beta (16E144f) y podría ser lo que está causando sudoun retraso de hasta 10 minutos, ya que es el cambio más reciente que recuerdo desde que ocurrió este problema. Nunca he tenido que esperar tanto para un programa básico y algo está claramente mal. El comando finalmente tiene éxito, pero después de esperar demasiado tiempo.

He estado usando esta pregunta como referencia. Hasta ahora, he intentado agregar mi nombre de host al final de la 127.0.0.1línea /etc/hostsy también. Verifiqué /etc/resolv.confy tuve algunas entradas adicionales de cuando estaba en una red que necesitaba entradas DNS manuales, pero las eliminé y no ha habido ninguna diferencia. Usé el networksetup -setdnsserverscomando para restaurar los valores originales. Internet todavía funciona bien pero sigue siendo muy lento sudo.

Intenté el logger 'test'comando pensando que escribiría /var/log/system.log, pero parece que eliminó totalmente ese archivo, aunque pronto se hizo de nuevo.

Esperaba usar el stracecomando para ver qué sucedía mientras se sudoejecutaba, pero ese comando no está disponible en OS X. ¿Alguien ha tenido este problema en este sistema operativo antes?

/var/log/system.log tiene los siguientes mensajes que pueden ser relevantes. Nuevamente, el comando finalmente tiene éxito de la manera normal:

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

Cualquier ayuda sería apreciada.

— Spencer Williams
fuente

¿Importa qué comando ejecutas en sudo? ¿Cómo se relacionan las marcas de tiempo en el registro con su acción de ejecutar sudo y en sudo? Veo opendirectoryd allí, ¿trabaja con una cuenta local o una cuenta de red? ¿Qué sucede si cambias de usuario (o configuras uno nuevo localmente)? ¿Sudo también es lento allí?

— nohillside

Estoy ejecutando la misma versión beta y sudo es tan rápido como siempre en realidad.

— nohillside

1

@patrix Ah, está bien. Sí, muy bien podría ser otra cosa. Sí, no importa qué comando use con sudo, el retraso es constante. Básicamente, el comando comienza alrededor de esa línea de registro com.apple.quicklooky finalmente termina al final, por lo que en ese ejemplo fueron aproximadamente 8 minutos con todos esos mensajes en el medio. El mensaje opendirectoryd parece aparecer cada vez que finalmente se ejecuta sudo lsen mi directorio de inicio local. En este momento solo estoy trabajando con carpetas locales. Solo tengo un usuario en esta computadora, aunque puedo ver qué sucede con una nueva cuenta ...

— Spencer Williams

@patrix Acabo de crear otro usuario con privilegios de administrador. Lamentablemente, esa cuenta tiene el mismo problema.

— Spencer Williams

11

La respuesta de ErikMH me dio la idea de intentar primero revertir el archivo sudoers, sin revertir / actualizar todo mi sistema nuevamente. En resumen:

Ejecute esto para obtener un shell raíz: sudo -s
Haz una copia de /private/etc/sudoers
Correr: cp /private/etc/sudoers\~orig /private/etc/sudoers
Corregir permisos ejecutando: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
Mueva los archivos /private/etc/sudoers.d/lejos de allí
Prueba sudoen otra terminal
No olvide salir de este shell para evitar ejecutar inadvertidamente comandos como root cuando no quiera

Ahora correr sudodebería funcionar de nuevo.

El siguiente paso es verificar las diferencias entre el archivo antiguo de sudoers (que copió en el paso 2) y el actual y agregar esos cambios paso a paso /private/etc/sudoerso /private/etc/sudoers.d/cada vez que ejecute un comando sudopara verificar si el cambio lo rompe.

En mi caso, había especificado un grupo inexistente en el archivo sudoers. Corregir eso solucionó mi problema.

— Cedric Dubois
fuente

trabajado en macOS 10.13!

— Nisba

También funcionó para mí (OSX 10.13). También tuve el mismo problema: grupo inexistente en el archivo sudoer.

— Petr Cibulka

Hmm ... No recuerdo haber cambiado el archivo sudoers en la máquina donde tuve este problema, pero desearía haber intentado lo que sugieres en lugar de restaurar mi sistema.

— Spencer Williams

Seguí adelante y acepté su respuesta porque parece que la gente está confirmando que ayuda, y seguro que desearía haberlo intentado primero, y generalmente no recomiendo restaurar todo su sistema.

— Spencer Williams

2

Esto puede ocurrir al actualizar a 10.12.4 si alguna vez ha editado el archivo / private / etc / sudoers.

La solución más fácil es:

Regrese a una versión anterior del sistema (siempre clona su sistema antes de actualizar, ¿verdad?)
Eliminar / privado / etc / sudoers
Copiar / private / etc / sudoers ~ orig a sudoers
Restablecer la propiedad de sudoers a system / root - solo lectura
Actualice el sistema a 10.12.4

— ErikMH
fuente

"Esto puede ocurrir al actualizar a 10.12.4 si alguna vez ha editado el archivo / private / etc / sudoers". ¿Sabemos lo que realmente lo está causando?

— Wowfunhappy

1

Desearía haber encontrado la causa real de esto, pero solo pude resolver el problema después de restaurar el software del sistema. Anteriormente estaba en la versión beta pública de macOS Sierra, pero ahora estoy en la versión principal.

Estoy cargando lentamente todos mis programas y notaré si vuelvo a retrasarme sudo.

— Spencer Williams
fuente

0

Tenía un archivo /etc/sudoers.d/que eliminé. Voila, sudoes rápido de nuevo.

— vidstige
fuente