¿Cómo determinar la causa de un reinicio en Kali Linux?

Podemos averiguar qué causó el reinicio a través de algunos métodos diferentes. Revisaremos esos métodos en esta publicación y usaremos programas accesibles e iniciaremos sesión en un sistema Linux para diagnosticar tales problemas.

No es raro descubrir que un sistema Linux se ha reiniciado inesperadamente o sin razón aparente. Encontrar y corregir la causa principal podría ayudar a prevenir problemas futuros y tiempos de inactividad inesperados.

Examinar el diario systemd

Si no tiene un systemd-journal persistente, no podrá conservar un diario persistente en el disco y sus registros se perderán cuando reinicie. Puede hacer esto editando /etc/systemd/journald .conf o creando manualmente el directorio siguiendo las instrucciones a continuación:

$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald

Después de eso, puede reiniciar la máquina si desea registrar más de una entrada reiniciada en el diario, aunque no es necesario.

Para obtener una lista de arranques registrados del diario, use el siguiente comando:

journalctl --list-boots

Como puede ver, el listado es para varias botas. Use el siguiente comando para ir más allá en un reinicio específico:

journalctl -b {num} -n

Examinar los mensajes del sistema

También puede conectar los mensajes del sistema con el reinicio que desea diagnosticar.

Los registros se encuentran en /var/log/messages en los sistemas CentOS/RHEL . Se registra en /var/log/Syslog en los sistemas Ubuntu/Debian . Para filtrar o descubrir datos específicos, solo use el comando tail o su editor de texto favorito.

Tales entradas indican un apagado/reinicio activado por un administrador o usuario raíz , como se puede ver en los registros a continuación. Estos mensajes difieren según el sistema operativo y cómo se inicia el reinicio/apagado , pero revisar los registros del sistema siempre brindará información útil, incluso si no siempre es lo suficientemente precisa como para identificar el motivo.

nano  /var/log/syslog

El siguiente es un ejemplo de un comando que se puede usar para filtrar los registros del sistema:

sudo grep -iv ‘: iniciando\|núcleo: .*: Botón de encendido\|mirando los botones del sistema\|Detuvo la limpieza\|Inició la recuperación del kernel’ \

 /var/log/messages /var/log/syslog /var/log/apcupsd* \

 | grep -iw ‘recuperar[az]*\|poder[az]*\|apagar[az]*down\|rsyslogd\|ups’

Es posible que los eventos capturados no siempre sean específicos. Siempre busque advertencias o problemas que puedan hacer que el sistema se apague o se bloquee.

Examinar el tiempo de reinicio

Puede usar los comandos who y last para ver cuándo se reinició el sistema.

who -b

last -x | head | tac

Verifique los registros auditados

Es una ubicación fantástica para inspeccionar varios eventos usando la herramienta de búsqueda para sistemas que usan auditd . Para verificar los dos últimos elementos en los registros de auditoría, use el siguiente comando.

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

Se informarán los dos apagados o reinicios más recientes. Todo debería estar bien si esto informa un SYSTEM_SHUTDOWN seguido de un SYSTEM_BOOT . Si devuelve dos o más líneas SYSTEM_BOOT seguidas o solo una línea SYSTEM_BOOT , el sistema no se cierra correctamente. El siguiente es un ejemplo de una salida típica:

—-

type=SYSTEM_SHUTDOWN msg=audit(Lunes 28 de junio 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=? dir=? terminal=? res=éxito’

—-

type=SYSTEM_BOOT msg=audit(Lunes 28 de junio 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=? dir=? terminal=? res=éxito’

En el resultado anterior se enumeran dos mensajes SYSTEM_BOOT sucesivos , lo que podría sugerir un apagado incorrecto si se conecta con los registros del sistema.

Conclusión

Un solo comando o un solo archivo de registro no siempre es suficiente para determinar el motivo de un reinicio de Linux . Como resultado, conocer los comandos y registros que registran los eventos relacionados con el sistema siempre es útil y puede reducir el tiempo que lleva descubrir la causa subyacente.

Los ejemplos anteriores pueden ayudarlo a comenzar con la solución de problemas. Puede estar seguro de saber qué sucedió y cómo se reinició su sistema si usa una combinación de tales herramientas y registros.