Un síntoma:
Cada acción de inicio de sesión como ssh, su, sudo o incluso una salida por parte de un usuario tarda cerca de un minuto.
Una llamada SSH es lenta aquí:
debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session.Y si hago strace -f su - el proceso de juan ls es lento aquí:
open("/etc/login.defs", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=10551, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f2c32202000 read(4, "#\n# /etc/login.defs - Configurat"..., 4096) = 4096 read(4, " issuing \n# the \"mesg y\" command"..., 4096) = 4096 read(4, " algorithm compatible with the o"..., 4096) = 2359 read(4, "", 4096) = 0 close(4) = 0 munmap(0x7f2c32202000, 4096) = 0 sendto(3, "<86>Feb 10 17:36:33 su[4088]: + "..., 52, MSG_NOSIGNAL, NULL, 0El problema está aquí, cuando un proceso intentó escribir en /dev/log :
12:12:23 connect(1, {sa_family=AF_LOCAL, sun_path="/dev/log"}, 110) = 0 <0.000008> 12:12:23 sendto(1, "<13>Feb 11 12:12:23 juan: hello "..., 37, MSG_NOSIGNAL, NULL, 0) = 37 <15.931766>Depuración de rsyslog :
2042.323399028:7f5a60003700: --------imuxsock calling select, active file descriptors (max 4): 0 4 2042.323419636:7f5a60003700: Message from UNIX socket: #0 2042.323434226:7f5a60003700: main Q: queue nearly full (10000 entries), but could not drop msg (iRet: 0, severity 6) 2042.323437267:7f5a60003700: main Q: doEnqSingleObject: queue FULL - waiting 2000ms to drain. 2044.323585582:7f5a60003700: main Q: doEnqSingleObject: cond timeout, dropping message! 2044.323616781:7f5a60003700: main Q: EnqueueMsg advised worker start/var/log/syslog y /var/log/messages están vacíos
Como explicó correctamente en su pregunta, el problema está en la parte de registro, obtiene un socket (1) para/dev/log, luego lo usa para enviar un mensaje tonto "hola juan", pero toma 15 segundos.
Estoy viendo lo mismo con un vsftpd, no se trata del servicio en sí, el problema está en su rsyslog. Probablemente, si lo reinicia, los 15 segundos se reducirán a casi nada, pero se acumulará con el tiempo.
Además, su cola de rsyslog está casi llena, lo que significa que su servidor remoto no está funcionando o su disco donde escribe los registros es completamente lento, supongo que es con la opción remota.
Este es un mensaje importante:
doEnqSingleObject: queue FULL - waiting 2000ms to drain.
No puedo proporcionar más información ya que estoy aquí porque tengo mis propios problemas, pero tal vez cambiar el tipo de cola podría ayudar.
Esto puede suceder por una amplia variedad de razones, sugeriría que un buen lugar para comenzar a depurar esto sería usar el argumento -vvv para generar un seguimiento más detallado de lo que está sucediendo, con suerte debería poder detectar qué parte de el proceso en el que está pendiente
por lo que su comando debería ser algo como: ssh foo@domain.com -vvv
Exactamente el problema de la aceptación lenta de una sesión ssh podría tener múltiples razones para la causa. Depende de si el usuario con el que está iniciando sesión está basado localmente o basado en ldap o AD. ssh con -vvv es una buena opción para verificar el ssh con el nivel máximo de registro de depuración, que le dará una mejor idea de dónde se bloquea. Verifique la cantidad de saltos entre el servidor desde el que intenta iniciar sesión en el servidor a través de traceroute.