¿Por qué el comando sudo tarda tanto en ejecutarse?

He estado adquiriendo Linux (Fedora 10, luego 11) en los últimos meses (y disfrutándolo inmensamente, es como descubrir computadoras de nuevo, muchas cosas que aprender).

Agregué mi usuario a la última línea del archivo / etc / sudoers como se muestra a continuación, para que no se me solicite mi contraseña cuando ejecuto el comando sudo:

MyUserName ALL = (ALL) NOPASSWD: ALL

Ahora, cada vez que ejecuto un comando usando sudo, hace una pausa notable antes de realizar la tarea (~ 10 segundos). ¿Por qué podría ser esto y cómo podría solucionarlo? Estoy ejecutando Sudo versión 1.7.1 en Fedora 11 x86 64.

Hice esta pregunta en SO y se mudó aquí. Dicho esto, ya no tengo la capacidad de editar la pregunta como si la tuviera, o incluso aceptar la respuesta correcta, pero esta resultó ser la verdadera razón por la cual y cómo resolverla:

Encontrado aquí El usuario "rohandhruva" de allí da la respuesta correcta:

Esto sucede si cambia el nombre de host durante el proceso de instalación.

Para resolver el problema, edite el archivo / 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>

Compruebe que su demonio syslog funciona correctamente; Esto me causó el problema.

Ejecute el siguiente comando

logger 'Hello world'

1. ¿Regresa el comando dentro de un tiempo razonable?

2. ¿Aparece 'Hola mundo' /var/log/syslog?

Si este no es el caso, el demonio syslog se ha bloqueado. Reiniciarlo debería solucionar su problema.

¿Es uno de los archivos / directorios que necesita leer en un montaje en red, o de alguna manera está provocando la lectura desde un dispositivo USB lento? Intenta estirarte y ver dónde es lento; si pasa demasiado rápido, haz

sudo strace -r -o trace.log sudo echo hi

Cada línea comenzará con el tiempo transcurrido desde que ingresó la llamada al sistema anterior.

(El sudo inicial parece ser necesario; no sé cuánto perturbará los resultados).

Recientemente descubrí que tenía el mismo problema. No hubo retraso de sudo y, de repente, un retraso de aproximadamente 10-20 segundos. Determiné el problema específico usando:

 1. chmod u+s /usr/sbin/strace  (as the root user)

Como a ti mismo:

 1. sudo -K
 2. strace sudo /bin/tcsh

Y luego encuentre dónde cuelgan las llamadas del sistema.

En mi caso, descubrí que estaba colgando de una traducción DNS, aparentemente uno de los DNSen en mi lista /etc/resolv.confestaba muy borroso o salió mal. Así que cambié el orden de resolución y las cosas funcionaron rápidamente nuevamente.

No estoy seguro acerca de Fedora, pero he usado otros sistemas en los que sudo verificaría desde dónde inició sesión, lo que si su DNS no está bien configurado puede demorar mucho tiempo. Esto también se puede ver cuando SSH entra en la máquina: lleva mucho tiempo encontrar un aviso.

Tuve el mismo problema, revisé /var/log/auth.log y syslog en busca de errores. Resulta que mi servidor LDAP no pudo ser alcanzado y ralentizó todo.

Ya no usaba la autenticación basada en LDAP, así que eliminé todas las referencias "ldap" de /etc/nsswitch.conf

Desde entonces todo vuelve a funcionar como un encanto.

En muchos casos, se encuentra que el nombre de host (que se configuró en /etc/sysconfig/ network) no existe en el /etc/hostsarchivo; entonces, al agregar el archivo mencionado anteriormente, el archivo se abre rápidamente.

Tuve un problema similar, lo solucioné colocando el nombre de host (por ejemplo, mybox) y la salida completa del comando hostname (mybox.mydomain.com). Esto lo aclaró de inmediato. Pasó de 2 minutos para abrir / etc / hosts para acceso instantáneo.

Caso SELinux

Si el mismo comando sudo es lento solo en un demonio y rápido en la línea de comando, entonces lo más probable es que sea causado por SELinux . (SELinux = NSA Security-Enhanced Linux kernel module, habilitado en Fedora por defecto).

Un caso típico es un servidor http y un script especial para la administración del servidor, restringido en sudoers:

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

Es típico en este caso que no se informe nada sobre SELinux en el registro de auditoría ausearch -m avc -ts today, pero el script se ejecutará rápidamente si deshabilitamos temporalmente la aplicación por parte de setenforce 0. (y luego volver a habilitar por setenforce 1)

Los únicos mensajes relevantes en el registro del sistema (journalcrl) son estos después del retraso de 25 segundos:

... sudo [...] pam_systemd (sudo: sesión): no se pudo crear la sesión: no se recibió respuesta. Las causas posibles incluyen: la aplicación remota no envió una respuesta, la política de seguridad del bus de mensajes bloqueó la respuesta, el tiempo de espera de respuesta expiró o la conexión de red se interrumpió.
... sudo [...]: pam_unix (sudo: sesión): sesión abierta para el usuario root por (uid = 0)

El registro de todos los mensajes SElinux "no auditar" silenciados puede habilitarse semodule -DBy deshabilitarse nuevamente mediante semodule -B.
(Espero escribir pronto un módulo de política de SELinux pronto para este caso aquí o se puede usar un método de esta respuesta ).

Al mirar el sudoersarchivo de muestra que tengo, creo que se supone que debe haber un espacio después del NOPASSWD:bit.

Verifique su archivo / etc / hosts y asegúrese de tener una entrada para 127.0.0.1

( fuente )

Después de solucionar cualquier problema de host, asegúrese de borrar cualquier caché de DNS defectuoso si está ejecutando una aplicación de almacenamiento en caché de DNS como nscd:

/etc/init.d/nscd force-reload

Para mí fue instalar krb5-user / config / locales. Noté esto al examinar /var/log/auth.log. El uso de apt-get remove para desinstalar esos paquetes lo arregló. No elimine esos paquetes si está en una computadora que requiere kerberos (pam_krb5) obviamente.

¿Estás utilizando LDAP para la autenticación?

Si es así, probablemente desee utilizar la política de vinculación suave. En /etc/ldap/ldap.conf (o /etc/ldap.conf):

bind_policy soft

Parece que tienes algún tipo de tiempo de espera en tu cadena de autenticación. Comprueba cómo sudo intenta autenticarse y busca cuellos de botella.

Estuche Systemd

Para mí, mi sistema se había quedado sin memoria y se bloquearon muchos procesos. Mi sistema se basa en systemd y algo se había bloqueado. Me cuesta recordar todo lo que hice, pero:

• systemctl status <any.service> tiempo de espera
• No pude sudo reboot(basado en systemd)

Solución

Un reinicio solucionó mi problema, pero para mí fue solo una venda. Aún necesita saber por qué se quedó sin memoria / se bloqueó.