Tutoriales

¿Cómo encontrar el motivo de un reinicio de Linux?

A menudo encontramos que los sistemas Linux se reinician de manera no planificada o por razones aparentes desconocidas. Encontrar y abordar la causa raíz puede ayudar a evitar que estos problemas vuelvan a ocurrir y evitar el tiempo de inactividad no planificado.

Hay varias formas de averiguar qué provocó el reinicio. En este artículo, discutiremos estos métodos y cómo aprovechar las utilidades y los registros disponibles en los sistemas Linux para resolver tales situaciones.

Comprobar el tiempo de reinicio

Puede comprobar cuándo se reinicia el sistema who y last Pedido

$ 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 para que se diagnostique con un mensaje del sistema.

Para los sistemas CentOS/RHEL, puede encontrar registros en /var/log/messages Y para los sistemas Ubuntu/Debian, inicia sesión en /var/log/syslogSimplemente puede usar tail comando o su editor de texto favorito para filtrar o encontrar datos específicos.

Como puede deducirse de los registros a continuación, estas entradas indican un apagado/reinicio iniciado por el administrador o el usuario root. Estos mensajes pueden variar según el tipo de sistema operativo y cómo se activa el reinicio/apagado, pero siempre puede encontrar información útil consultando el registro del sistema, aunque es posible que no sea lo suficientemente claro como para identificar la causa cada vez.

LEER  Tutorial de AnyDesk en alemán: instalación y uso en Linux
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.

A continuación se proporciona un comando que se puede usar para filtrar los registros del sistema:

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. Siempre realice un seguimiento de los eventos que podrían provocar cortes de energía del sistema/advertencias de fallas o señales de errores.

Verificar registros de auditoría

para el sistema auditdque es un buen lugar para comprobar los diferentes eventos ausearch herramienta. Verifique las dos últimas entradas en el registro de auditoría con los siguientes comandos.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

Esto informará los dos últimos apagados o reinicios.Si esto informa un SYSTEM_SHUTDOWN Seguido por SYSTEM_BOOT, todo debería estar bien.Sin embargo, si informa ambos SYSTEM_BOOT una linea o solo una linea SYSTEM_BOOT Bien, entonces lo más probable es que el sistema no se apagó correctamente. La salida normal debería verse así:

$ 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 resultado a continuación enumera dos SYSTEM_BOOT mensaje, aunque debe estar asociado con el registro del sistema, puede indicar un apagado anormal.

$ 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 registros del sistema

Debe tener un systemd-journal persistente para mantener un diario persistente en el disco; de lo contrario, el diario no persistirá durante los reinicios.Para esto, puedes /etc/systemd/journald.conf O cree el directorio usted mismo con:

$ 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 optar por reiniciar el sistema para capturar varias entradas de reinicio en el registro, pero esto no es obligatorio.

Utilice el siguiente comando para enumerar los arranques registrados en el registro:

$ 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 puede ver, enumera varios pares de botas. Para analizar más a fondo un reinicio específico, utilice:

$ journalctl -b {num} -n

aquí {num} será el índice dado journalctl --list-boots El comando está 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 registro en el resultado anterior y puede rastrear la excepción (si la hay).

en conclusión

Es posible que el uso de un solo comando o un solo archivo de registro no siempre pueda identificar la causa de un reinicio de Linux. Por lo tanto, conocer los comandos y registros que capturan los eventos relacionados con el sistema siempre es conveniente y puede reducir el tiempo necesario para encontrar la causa raíz.

Los ejemplos anteriores le brindan un punto de partida para comenzar a solucionar problemas. Usando una combinación de estas herramientas y registros, puede saber con confianza qué sucedió y cómo se reinició su sistema.

A continuación, descubra algún software de monitoreo liviano para Linux.

LEER  Cómo acceder a la configuración de UEFI desde Linux

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba