¿Cómo encontrar la razón de reinicio de Linux?

A menudo ocurre que nos encontramos con que un sistema Linux se ha reiniciado de forma imprevista o debido a razones aparentemente desconocidas. Encontrar y resolver la causa raíz puede ayudar a prevenir la recurrencia de estos problemas y evitar tiempos de inactividad no planificados.

Hay varias formas de averiguar qué ha provocado un reinicio. En este artículo, vamos a discutir esas maneras y cómo puede utilizar las utilidades y registros disponibles en un sistema Linux para solucionar problemas en tales escenarios

Inspeccionar el tiempo de reinicio

Puede comprobar cuándo se produce el reinicio del sistema con los comandos who y last

$ who -b
system boot 2021-02-13 20:51

$ last -x | head | tac
abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46)
reboot system boot 3.

10.

0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in

Compruebe los mensajes del sistema

Puede correlacionar aún más el reinicio que desea diagnosticar con los mensajes del sistema

Para los sistemas CentOS/RHEL, encontrará los registros en /var/log/messages mientras que para los sistemas Ubuntu/Debian, se registran en /var/log/syslog. Puede utilizar simplemente el comando tail o su editor de texto favorito para filtrar o encontrar datos específicos

Como puede deducirse de los registros siguientes, estas entradas sugieren un apagado/reinicio iniciado por un administrador o usuario root. Estos mensajes pueden variar dependiendo del tipo de sistema operativo y de la forma en que se active el reinicio/apagado, pero siempre encontrará información útil mirando los registros del sistema, aunque puede que no sea lo suficientemente explícito como para señalar la causa cada vez que se produzca un reinicio/apagado.

Feb 13 19:56:20 centos7vm chronyd<x>[637]</x>: Fuente 72.30.35.89 sustituida por 142.147.92.5
Feb 13 20:00:40 centos7vm chronyd<x>[637]</x>: Fuente seleccionada 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Creado slice de usuario root.
Feb 13 20:01:01 centos7vm systemd: Iniciada sesión 2 del usuario root.
Feb 13 20:04:09 centos7vm systemd-logind: El sistema se está apagando.
Feb 13 20:04:09 centos7vm systemd: Cerrado el socket del demonio de sondeo LVM2.
Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User

Sistema
Uno de estos comandos que puede utilizar para filtrar los registros del sistema es el que se indica a continuación

sudo grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
 /var/log/messages /var/log/syslog /var/log/apcupsd* \
 | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

Los eventos capturados pueden no ser siempre específicos. Rastree siempre los eventos que den indicios de advertencias o errores que puedan provocar el apagado/cierre del sistema

Verificar los registros auditd

Para los sistemas con auditd, es un buen lugar para comprobar diferentes eventos utilizando la herramienta ausearch. Utilice el siguiente comando para comprobar las dos últimas entradas de los registros de auditoría

$ sudo ausearch -i -m sistema_arranque,sistema_apagado | tail -4

Esto reportará los dos apagados o reinicios más recientes. Si esto reporta un SYSTEM_SHUTDOWN seguido de un SYSTEM_BOOT, todo debería estar bien. Pero, si reporta dos líneas SYSTEM_BOOT seguidas o sólo una línea SYSTEM_BOOTentonces lo más probable es que el sistema no se apagó con gracia. Una salida normal debería ser algo como lo siguiente

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(sábado 13 de febrero de 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(sábado 13 de febrero de 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

$
La siguiente salida muestra dos mensajes SYSTEM_BOOT consecutivos, lo que puede indicar un apagado sin gracia, aunque debe correlacionarse con los registros del sistema

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(sábado 13 de febrero de 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(sábado 13 de febrero de 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'

Analizar el diario de systemd

Debe tener un systemd-journal persistente para mantener un diario persistente en el disco, de lo contrario los registros no persistirán al reiniciar. Para ello, puede hacer los cambios en /etc/systemd/journald.conf o cree el directorio usted mismo con los siguientes comandos

$ sudo mkdir /var/log/journal

 sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null

 sudo systemctl -s SIGUSR1 kill systemd-journald

Una vez hecho esto, puede reiniciar opcionalmente el sistema para capturar más de una entrada de reinicio en el diario aunque no sea necesario

Utilice el siguiente comando para listar los reinicios registrados en el diario

$ journalctl --list-boots

Aquí está su salida en mi servidor

$ journalctl --list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST-Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST-Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST-Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST-Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 vie 2020-12-11 10:43:55 IST-vie 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 vie 2020-12-11 19:04:30 IST-vie 2020-12-11 19:31:01 IST
 -9 2acf08368667423c89086579f98efd82 mar 2020-12-15 17:36:52 IST-mar 2020-12-15 19:13:10 IST
 -8 b826f223a67d454b94d4413678870f08 sáb 2020-12-19 00:31:54 IST-sáb 2020-12-19 00:44:52 IST
 -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST-Wed 2020-12-23 23:02:44 IST
 -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST-Mon 2020-12-28 22:54:22 IST
 -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST-Tue 2020-12-29 19:39:38 IST
 -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST-Wed 2020-12-30 19:20:23 IST
 -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST-Thu 2020-12-31 15:45:36 IST
 -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST-Sat 2021-02-13 20:10:

44 TSI


 -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST-Sat 2021-02-13 20:23:18 IST
 0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST-Sat 2021-02-13 21:13:15 IST

$
Como puede ver el listado dura varios reinicios. Para analizar más a fondo un reinicio en particular, utilice

$ journalctl -b {num} -n

Aquí {num} será el índice dado en el comando journalctl --list-boots en la primera columna

$ journalctl -b -1 -n
-- Los registros comienzan en Wed 2020-11-18 23:09:05 IST, finalizan en Sat 2021-02-13 21:13:39 IST. --
13 de febrero 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: lvm2-monitor.service: Realizado con éxito.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: Detenida la monitorización de réplicas LVM2, instantáneas, etc. usando dmeventd o sondeo de progreso.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: Alcanzado objetivo Apagado.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: Reached target Final Step.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: systemd-poweroff.service: Exitoso.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: Power-Off finalizado.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[</x></x></x></x></x></x></x></x>1]: Alcanzado objetivo Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1<x><x><x><x><x><x><x><x>]</x></x></x></x></x></x></x></x>: Apagando.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown<x><x><x><x><x><x><x><x>[</x></x></x></x></x></x></x></x>1]: Sincronizando sistemas de archivos y dispositivos de bloque.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]:

Diario

 detenido

$
Puede observar los mensajes registrados en el diario en la salida anterior y puede rastrear las anomalías si las hubiera

Conclusión

Puede que no siempre sea posible precisar la causa de un reinicio de Linux utilizando un único comando o a partir de un único archivo de registro. Por ello, siempre es útil conocer los comandos os y registros que capturan los eventos relacionados con el sistema y que pueden acortar el tiempo necesario para encontrar la causa raíz

Los ejemplos anteriores le proporcionan un punto de partida para empezar a solucionar problemas. Utilizando una combinación de dichas herramientas y registros, puede estar seguro de saber qué ocurrió y cómo se reinició su sistema.

A continuación, descubra algunos de los programas ligeros de monitorización para Linux.

Abhishek Nair

Autor