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

83

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.

linux permissions sudo anon
fuente
Técnicamente esto cuenta como editar un guión, ¿verdad? ¿No es un script un programa?
66
NOPASSWD: se considera un riesgo de seguridad y derrota el propósito de tener que usar sudo en primer lugar.
Puedo comprar eso, pero el problema sigue siendo por qué tarda tanto.
2
¿De dónde obtiene esta máquina los usuarios y la autenticación? LDAP, ¿posiblemente con Kerberos quizás?
wzzrd
1
Posible duplicado de Cada vez que uso sudo se cuelga antes de completar
Harry Tsai

Respuestas:

123

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>
Cuga
fuente
3
Muy bien. Es sorprendente que distribuciones como Fedora no editen / etc / hosts si cambias tu nombre de host en el momento de la instalación, pero lo que sea. ¡Eso es código abierto para ti!
dimo414
Esto solucionó mi uso lento de sudo, ¡gracias! Edité / etc / hostname, y simplemente olvidé editar el archivo / etc / hosts.
Joe
2
Agregar su nombre de host a la línea 127.0.0.1 o :: 1 puede causar que cierto software relacionado con el servidor se vincule al nombre de host / IP / interfaz correcto. Un ejemplo de ello es Cloudera Manager, los servicios de hadoop obtienen el nombre de host incorrecto y confunden a CM porque todos se resuelven en localhost. Sugiero leer otra respuesta a continuación para una posible solución. Esto puede o no causar problemas a una estación de trabajo independiente que no tendrá otras computadoras conectadas a ella.
ddcruver
1
También puede ser /etc/nsswitch.conf (por razones similares). El mío se configuró en "hosts: archivos dns" y, por lo tanto, estaba buscando mi nombre de host en un servidor DNS con un largo tiempo de espera. Lo cambié a "hosts: archivos dns" y ahora se verá primero en / etc / hosts. Gracias por esta respuesta, que me llevó a buscar en nsswitch.conf!
Alan Porter
1
Es ridículo que esta sea la solución. ¿Por qué en el mundo el sudocomando tiene que mirar el nombre de host para funcionar? ¿Con qué tiene que ver mi nombre de host sudo echo hello? De todos modos, gracias por la respuesta
smac89
24

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.

galgalesh
fuente
99
Sorprendentemente, ese fue el problema para mí. Quién lo hubiera pensado. La solución para mí fue simplemente reiniciar syslog. service rsyslog restart
MikeKulls
Igual que aquí. service rsyslog restartreparó mis comandos de sudo lento.
Pedro Cordeiro
Sorprendentemente, ese fue el problema para mí. Antes de eso, toda la solicitud del servidor es muy lenta. Solo quiero saber por qué.
Michael Wang
10

¿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).

ysth
fuente
Gracias. Esto está en la unidad de disco duro, sin USB o unidad de red.
@ Cuga: ¿y qué aprendiste de strace?
@oligofren: necesitas hacer sudo strace
ysth
8

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.

mdpc
fuente
¡La mejor respuesta (para mí)! Descubrí que mi DBus Broker estaba fallando en la desconexión de la red y sudo / KDE estaba agotando el tiempo de conexión. ¡Gracias!
PSSGCSim
Gracias, esto me ayudó. También tuve que deshacer un cambio anterior en la hostslínea en mi /etc/nsswitch.conf. Había agregado "resolver dns" como prefijo al hostsvalor. Cuando eliminé este prefijo, sudo fue rápido nuevamente.
mnieber
5

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.

Colin Coghill
fuente
5

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.

Sakuraba
fuente
¿Por qué publica una respuesta obviamente no relacionada (el OP no utilizó LDAP) a una pregunta de cinco años?
Sven
77
Porque podría ayudar a cualquiera. Revisé todas las cosas que se mencionaron aquí, pero nada ayudó. Alguien más podría enfocarse en mirar en la dirección correcta con mi respuesta al verificar si tiene algún problema de conexión LDAP como la razón subyacente del comando sudo lento e insensible. Es tan relevante como las respuestas relacionadas con DNS en que algo detrás de las cubiertas tiene la culpa que no es directamente visible para el usuario. Considero este sitio como una fuente general de conocimiento y no solo como un tipo único de sitio web de preguntas / respuestas. Se trata de recopilar conocimientos relevantes.
Sakuraba
66
Además, ¿quién en el infierno azul eres para desacreditar mi ayuda? Este sitio funciona porque se incentiva el intercambio de conocimientos, no porque las personas tengan un voto negativo. Si no te gusta, entonces tienes derecho a ignorarlo.
Sakuraba
5

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.

Zahid Hussain
fuente
3

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.


fuente
3

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 ).

hynekcer
fuente
Gracias por esta información. A partir de la información aquí, pude encontrar un artículo relacionado que señalaba la posibilidad de fprintd(la autenticación de huellas digitales) el culpable. Eliminando fprintdy fprintd-pamresolvió el problema por mí.
KevinO
@KevinO Complacido de que te ayudó a encontrar una solución. Sin embargo, sabía que mi problema era muy específico y que mi contribución a la pregunta debería ser solo el método para diagnosticar o excluir una sospecha sobre SELinux.
hynekcer
¡Absolutamente le di un +1! Fue el bus de mensajes el que condujo a una solución. Había mirado un par de veces en sudo lento, pero la tuya era la pista que necesitaba.
KevinO
1

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

Chris Jester-Young
fuente
Agregué un espacio, pero todavía tiene el retraso. Gracias por la sugerencia.
1

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

( fuente )

Ryan Emerle
fuente
1

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
Roger Smith
fuente
1

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.

Halsafar
fuente
0

¿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
jtimberman
fuente
0

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.

towo
fuente
0

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ó.

Eric Fossum
fuente