¿Por qué Sudo tarda demasiado?

Recientemente actualicé a macOS Sierra 10.12.4 Beta (16E144f) y podría ser lo que está causando sudoel 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 por un programa básico y claramente algo anda mal. El comando finalmente tiene éxito, pero después de esperar demasiado.

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. Revisé /etc/resolv.confy tenía algunas entradas adicionales de cuando estaba en una red que necesitaba entradas de 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.

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

Esperaba usar el stracecomando para ver qué sucedía mientras sudose ejecutaba, pero ese comando no está disponible en OS X. ¿Alguien se ha encontrado con 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 como de costumbre:

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.

¿Importa qué comando ejecutas a través de sudo? ¿Cómo se relacionan las marcas de tiempo en el registro con su acción de ejecutar sudo y ejecutar sudo? Veo opendirectoryd allí, ¿trabaja con una cuenta local o una cuenta de red? ¿Qué sucede si cambia de usuario (o configura uno nuevo localmente), sudo también es lento allí?
Estoy ejecutando la misma versión beta y Sudo es tan rápido como siempre.
@patrix Ah, está bien. Sí, muy bien podría ser otra cosa. Sí, sucede sin importar 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 ocurrir 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 que pasa con una cuenta nueva...
@patrix Acabo de crear otro usuario con privilegios de administrador. Lamentablemente, esa cuenta tiene el mismo problema.

Respuestas (4)

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

  1. Ejecute esto para obtener un shell raíz:sudo -s
  2. hacer una copia de/private/etc/sudoers
  3. Correr:cp /private/etc/sudoers\~orig /private/etc/sudoers
  4. Corrija los permisos ejecutando:chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
  5. Mueva cualquier archivo /private/etc/sudoers.d/lejos de allí
  6. Prueba sudoen otro terminal
  7. No olvide salir de este shell para evitar ejecutar comandos sin darse cuenta como root cuando no tiene la intención de hacerlo.

Ahora correr sudodebería funcionar de nuevo.

El siguiente paso es verificar las diferencias entre el antiguo archivo sudoers (que copió en el paso 2) y el actual y agregar esos cambios paso a paso de nuevo a /private/etc/sudoerso /private/etc/sudoers.d/, cada vez que ejecute un comando usando 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.

trabajado en macOS 10.13!
A mí también me funcionó (OSX 10.13). También tuve el mismo problema: grupo inexistente en el archivo sudoer.
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.
Continué y acepté su respuesta porque parece que la gente está confirmando que ayuda, y desearía haber probado esto primero, y generalmente no recomiendo restaurar todo su sistema.
En el paso 3 me sale un errorcp: /private/etc/sudoers~orig: No such file or directory

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

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

  1. Regrese a una versión anterior del sistema (siempre clona su sistema antes de actualizar, ¿verdad?)
  2. Eliminar /private/etc/sudoers
  3. Copie /private/etc/sudoers~orig a sudoers
  4. Restablecer la propiedad de sudoers a sistema/raíz: solo lectura
  5. Actualice el sistema a 10.12.4
"Esto puede ocurrir al actualizar a 10.12.4 si alguna vez editó el archivo /private/etc/sudoers". ¿Sabemos qué es lo que realmente lo está causando?

Ojalá hubiera podido encontrar 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 principal.

Estoy cargando lentamente todos mis programas y notaré si vuelvo a experimentar un retraso sudo.

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

¿Por qué Sudo tarda demasiado?
RespuestasAquíPolítica de privacidad1y, 0v