A menudo sucede que nos encontramos con un sistema Linux que se ha reiniciado de forma no planificada o por razones aparentes desconocidas. Encontrar y resolver la causa raíz puede ayudar a prevenir la recurrencia de tales problemas y evitar el tiempo de inactividad no planificado.
Hay varias formas de averiguar qué provocó un reinicio. En este artículo, analizaremos esas formas y cómo puede utilizar las utilidades disponibles y los registros en un sistema Linux para solucionar estos escenarios.
Tabla de contenido
Inspeccionar el tiempo de reinicio
Puede verificar cuándo ocurrió 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 $
Revisa 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, está registrado en /var/log/syslog. Simplemente puede usar el comando tail o su editor de texto favorito para filtrar o encontrar datos específicos.
Como se puede inferir de los registros a continuación, tales entradas sugieren un apagado/reinicio iniciado por un administrador o usuario raíz. Estos mensajes pueden variar según el tipo de sistema operativo y la forma en que se activa el reinicio/apagado, pero siempre encontrará información útil al consultar los registros del sistema, aunque es posible que no sea lo suficientemente explícito para señalar la causa cada vez.
Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5 Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123 Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root. Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root. Feb 13 20:04:09 centos7vm systemd-logind: System is powering down. Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket. Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.
Uno de esos comandos que puede usar para filtrar los registros del sistema se proporciona 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 señales de advertencias o errores que puedan provocar que el sistema se apague o se bloquee.
Verificar registros auditados
Para sistemas con auditd, es un gran lugar para verificar diferentes eventos utilizando la herramienta de búsqueda. Use el siguiente comando para verificar las dos últimas entradas de los registros de auditoría.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Esto informará los dos apagados o reinicios más recientes. Si esto informa un SYSTEM_SHUTDOWN seguido de un SYSTEM_BOOT, todo debería estar bien. Pero, si informa dos líneas SYSTEM_BOOT seguidas o solo una sola línea SYSTEM_BOOT, lo más probable es que el sistema no se apagó correctamente. 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(Saturday 13 February 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(Saturday 13 February 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' $
El siguiente resultado enumera dos mensajes SYSTEM_BOOT consecutivos, que pueden indicar un apagado incorrecto, aunque debe correlacionarse con los registros del sistema.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 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(Saturday 13 February 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 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 esto, 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-journald
Una vez hecho esto, puede reiniciar el sistema opcionalmente para capturar más de una entrada de reinicio en el diario, aunque no es obligatorio.
Use el siguiente comando para enumerar las botas registradas desde 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 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST -10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 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 IST -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 podéis ver está listado dura varias botas. Para analizar más a fondo un reinicio en particular, use:
$ journalctl -b {num} -n
Aquí {num} será el índice dado en el comando journalctl –list-boots en la primera columna.
$ journalctl -b -1 -n -- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. -- Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step. Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down. Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices. Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped $
Puede observar los mensajes registrados en el diario en el resultado anterior y puede rastrear las anomalías, si las hay.
Conclusión
Es posible que no siempre sea posible identificar la causa de un reinicio de Linux usando un solo comando o desde un solo archivo de registro. Como tal, siempre es útil conocer los comandos y registros que capturan eventos relacionados con el sistema y pueden acortar el tiempo necesario para encontrar la causa principal.
Los ejemplos anteriores le brindan un punto de partida para comenzar con la solución de problemas. Al usar una combinación de tales herramientas y registros, puede estar seguro de saber qué sucedió y cómo se reinició su sistema.
A continuación, descubra algunos de los software de monitoreo livianos para Linux.