Estoy ejecutando una caja Ubuntu 16.04.3 LTS de Linode, que está muy infrautilizada, pero el monitor de tiempo de actividad me dijo que mis sitios estuvieron inactivos durante casi una hora antes de que volvieran a funcionar. Revisé y encontré que el servidor se reinició y fue entonces cuando el sitio se recuperó. Recibí un correo electrónico de Linode que Host initiated restart. Las alertas configuradas dentro de Linode sobre un umbral de uso alto tampoco se activaron.
Estoy tratando de averiguar qué pasó. He visto un problema en otro sistema de ejecución de Ubuntu con Linode, en el que el soporte de Linode me dijo que algo causó que Linode fallara y Lassie (su perro guardián) lo reinició, que es exactamente lo que parece haber sucedido aquí.
He comprobado ambos /var/log/auth.log& /var/log/syslogpero parece que les faltan entradas de registro entre 18:03cuál 18:57es la ventana de tiempo de inactividad. Ningún mensaje destaca como tal. No hay ningún /var/log/messagesregistro en mi servidor.
Contenido de /var/log/syslog:
Feb 23 18:03:04 localhost alertyo-engine[6279]: Un-Setting flag
Feb 23 18:03:04 localhost alertyo-engine[6279]: Alloc = 1 MiB#011TotalAlloc = 2470 MiB#011HeapAlloc = 1 MiB#011Sys = 10 MiB#011NumGC = 10856
Feb 23 18:57:14 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="3304" x-info="http://www.rsyslog.com"] start
Feb 23 18:57:14 localhost rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]
Feb 23 18:57:14 localhost rsyslogd: rsyslogd's groupid changed to 108
Feb 23 18:57:14 localhost rsyslogd: rsyslogd's userid changed to 104
Feb 23 18:57:14 localhost systemd[1]: Mounted FUSE Control File System.
Contenido de /var/log/auth.log:
Feb 23 18:03:01 localhost CRON[29814]: pam_unix(cron:session): session closed for user root
Feb 23 18:03:01 localhost CRON[29813]: pam_unix(cron:session): session closed for user ashfame
Feb 23 18:57:14 localhost CRON[3301]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:57:15 localhost systemd-logind[3312]: Watching system buttons on /dev/input/event0 (Power Button)
Feb 23 18:57:15 localhost systemd-logind[3312]: New seat seat0.
Feb 23 18:57:15 localhost sshd[3449]: Server listening on 0.0.0.0 port 22.
Feb 23 18:57:15 localhost sshd[3449]: Server listening on :: port 22.
Feb 23 18:57:16 localhost CRON[3301]: pam_unix(cron:session): session closed for user ashfame
Feb 23 18:58:01 localhost CRON[3681]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 23 18:58:01 localhost CRON[3680]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:58:01 localhost CRON[3681]: pam_unix(cron:session): session closed for user root
Feb 23 18:59:01 localhost CRON[3787]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 23 18:59:01 localhost CRON[3786]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:59:01 localhost CRON[3787]: pam_unix(cron:session): session closed for user root
Feb 23 18:59:01 localhost CRON[3786]: pam_unix(cron:session): session closed for user ashfame
¿Qué más puedo comprobar? Si este fuera un problema recurrente, probablemente podría configurar más elementos de registro para descubrir qué está saliendo mal, pero como la última vez (que estaba en otro cuadro), me temo que esto ocurre una vez cada varios meses. ¿Cómo puedo saber lo que pasó en lugar de prepararme para cuando vuelva a suceder?
Respuesta1
Acabo de enterarme de que esto fue causado por un corte de energía en el centro de datos Fermont de Linode.
Entonces, si no ve nada en los registros de su servidor para tal problema, una causa sería que el servidor simplemente se apagó y, por lo tanto, no apareció nada en los registros (aunque recuerdo haber leído algo que algunos sistemas pueden hacer).
Siempre es una buena idea consultar la página de estado de su proveedor y la búsqueda de Twitter :)