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 repetición 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 formas 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 produjo el reinicio del sistema con los comandos who y last
$ who -b
arranque del sistema 2021-02-13 20:51
$ last -x | head | tac
abhishek pts/0 192.168.1.16 sáb 13 feb 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 sáb 13 feb 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 sáb 13 feb 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 sáb 13 feb 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 aún conectado
$Compruebe los mensajes del sistema
Puede correlacionar aún más el reinicio que desea diagnosticar con los mensajes del sistema.
En los sistemas CentOS/RHEL, encontrará los registros en /var/log/messages, mientras que en 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 activa el reinicio/apagado, pero siempre encontrará información útil mirando los registros del sistema, aunque puede que no sea lo suficientemente explícita como para señalar la causa cada vez.
Feb 13 19:56:20 centos7vm chronyd[637]: Fuente 72.30.35.89 reemplazada por 142.147.92.5
13 de febrero 20:00:40 centos7vm chronyd[637]: Fuente seleccionada 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Creado slice User Slice de root.
13 feb 20:01:01 centos7vm systemd: Iniciada Sesión 2 del usuario root.
13 de febrero 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 System.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 -4Esto 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_BOOT, entonces 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 sistema_arranque,sistema_apagado | 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 sistema_arranque,sistema_apagado | 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 realizar los cambios en /etc/systemd/journald.conf o crear 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-journalaldUna vez hecho esto, puede opcionalmente reiniciar el sistema para capturar más de una entrada de reinicio en el diario aunque no es necesario.
Utilice el siguiente comando para listar los reinicios registrados en el diario:
$ journalctl --list-bootsAquí 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 Vie 2020-12-11 10:32:44 IST-Vie 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 Lun 2020-12-28 16:54:11 IST-Lun 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 jue 2020-12-31 14:36:07 IST-ju 2020-12-31 15:45:36 IST
-2 a23c70804ec243f7868c18737f4b7e55 sáb 2021-02-13 20:09:30 IST-sáb 2021-02-13 20:10:44 IST
-1 94b604a6bf75462dac8c4a4576fdc863 sáb 2021-02-13 20:10:59 IST-sáb 2021-02-13 20:23:18 IST
0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sáb 2021-02-13 20:24:57 IST-Sáb 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} -nAquí {num} será el índice dado en el comando journalctl --list-boots en la primera columna.
$ journalctl -b -1 -n
-- Los registros comienzan el mié 2020-11-18 23:09:05 IST, finalizan el sáb 2021-02-13 21:13:39 IST. --
13 de febrero 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Realizado con éxito.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Detenida la monitorización de réplicas LVM2, instantáneas, etc. mediante dmeventd o sondeo de progreso.
13 de febrero, 20:23:18 ubuntumate20vm systemd[1]: Alcanzado el objetivo Apagado.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Alcanzado objetivo Paso Final.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Realizado con éxito.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finalizado el apagado.
13 feb 20:23:18 ubuntumate20vm systemd[1]: Alcanzado objetivo Power-Off.
13 feb 20:23:18 ubuntumate20vm systemd[1]: Apagando.
13 feb 20:23:18 ubuntumate20vm systemd-shutdown[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
No siempre es 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 comand 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.