¿Hay alguna manera de determinar si un servidor RHEL7 se reinició a través de systemctl (o alias de reinicio / apagado) o si el servidor se bloqueó? Pre-sistemad esto fue bastante fácil de determinar last -x runlevel, pero con RHEL7 no está tan claro.

Hay más de una forma de hacer esto, pero cubriré las 4 mejores que se me ocurran. (EDITAR: publiqué una versión limpia de esto como un artículo público en redhat.com. Consulte: Cómo distinguir entre un bloqueo y un reinicio elegante en RHEL 7 ).

(1) registros auditados

auditado es asombroso. Puede ver todos los diferentes eventos que registra marcando ausearch -m. A propósito del problema en cuestión, registra el apagado del sistema y el arranque del sistema, por lo que puede usar el comando ausearch -i -m system_boot,system_shutdown | tail -4. Si esto informa un SYSTEM_SHUTDOWN seguido de un SYSTEM_BOOT , todo está bien; sin embargo, si informa 2 líneas SYSTEM_BOOT seguidas, entonces claramente el sistema no se apagó correctamente, como en el siguiente ejemplo:

[root@a72 ~]# ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(09/20/2016 01:10:32.392:7) : pid=657 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(09/20/2016 01:11:41.134:7) : pid=656 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' 

(2) último -x

Igual que el anterior, pero con el last -n2 -x shutdown rebootcomando simple . Ejemplo donde el sistema se bloqueó:

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:11 - 01:20  (00:08)    
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:10 - 01:20  (00:09)    

O donde el sistema tuvo un reinicio elegante:

[root@a72 ~]# last -n2 -x shutdown reboot
reboot   system boot  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    
shutdown system down  3.10.0-327.el7.x Tue Sep 20 01:21 - 01:21  (00:00)    

(3) cree su propia unidad de servicio

Este es, en mi humilde opinión, el mejor enfoque porque puedes adaptarlo a lo que quieras. Hay un millón de formas de hacer esto. Aquí hay uno que acabo de inventar. Este próximo servicio solo se ejecuta en el apagado.

[root@a72 ~]# cat /etc/systemd/system/set_gracefulshutdown.service
[Unit]
Description=Set flag for graceful shutdown
DefaultDependencies=no
RefuseManualStart=true
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/bin/touch /root/graceful_shutdown

[Install]
WantedBy=shutdown.target
[root@a72 ~]# systemctl enable set_gracefulshutdown.service 
Created symlink from /etc/systemd/system/shutdown.target.wants/set_gracefulshutdown.service to /etc/systemd/system/set_gracefulshutdown.service.

Luego, cuando se inicia el sistema, este próximo servicio solo se iniciará si existe el archivo creado por el servicio de apagado anterior.

[root@a72 ~]# cat /etc/systemd/system/check_graceful.service 
[Unit]
Description=Check if system booted after a graceful shutdown
ConditionPathExists=/root/graceful_shutdown
RefuseManualStart=true
RefuseManualStop=true

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/bin/rm /root/graceful_shutdown

[Install]
WantedBy=multi-user.target
[root@a72 ~]# systemctl enable check_graceful
Created symlink from /etc/systemd/system/multi-user.target.wants/check_graceful.service to /etc/systemd/system/check_graceful.service.

Entonces, en cualquier momento, puedo verificar si el arranque anterior se realizó después de un apagado correcto haciendo systemctl is-active check_graceful, por ejemplo:

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
active
YAY
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2016-09-20 01:10:32 EDT; 20s ago
  Process: 669 ExecStart=/bin/rm /root/graceful_shutdown (code=exited, status=0/SUCCESS)
 Main PID: 669 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/check_graceful.service

Sep 20 01:10:32 a72.example.com systemd[1]: Starting Check if system booted after a graceful shutdown...
Sep 20 01:10:32 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

O aquí está después de un cierre sin gracia:

[root@a72 ~]# systemctl is-active check_graceful && echo YAY || echo OH NOES
inactive
OH NOES
[root@a72 ~]# systemctl status check_graceful
● check_graceful.service - Check if system booted after a graceful shutdown
   Loaded: loaded (/etc/systemd/system/check_graceful.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at Tue 2016-09-20 01:11:41 EDT; 16s ago
           ConditionPathExists=/root/graceful_shutdown was not met

Sep 20 01:11:41 a72.example.com systemd[1]: Started Check if system booted after a graceful shutdown.

(4) journalctl

Vale la pena mencionar que si configura systemd-journaldpara mantener un diario persistente, puede usar journalctl -b -1 -npara mirar las últimas líneas (10 por defecto) del inicio anterior ( -b -2es el inicio anterior, etc.). Ejemplo donde el sistema se reinicia con gracia:

[root@a72 ~]# mkdir /var/log/journal
[root@a72 ~]# systemctl -s SIGUSR1 kill systemd-journald
[root@a72 ~]# reboot
...
[root@a72 ~]# journalctl -b -1 -n
-- Logs begin at Tue 2016-09-20 01:01:15 EDT, end at Tue 2016-09-20 01:21:33 EDT. --
Sep 20 01:21:19 a72.example.com systemd[1]: Stopped Create Static Device Nodes in /dev.
Sep 20 01:21:19 a72.example.com systemd[1]: Stopping Create Static Device Nodes in /dev...
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Shutdown.
Sep 20 01:21:19 a72.example.com systemd[1]: Reached target Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Final Step.
Sep 20 01:21:19 a72.example.com systemd[1]: Starting Reboot...
Sep 20 01:21:19 a72.example.com systemd[1]: Shutting down.
Sep 20 01:21:19 a72.example.com systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Sep 20 01:21:19 a72.example.com systemd-journal[483]: Journal stopped

Si obtiene una buena salida como esa, entonces claramente el sistema se apagó con gracia. Dicho esto, no es súper confiable en mi experiencia cuando suceden cosas malas (fallas del sistema). A veces la indexación se vuelve rara.

Es curioso, anoche reinicié un sistema CentOS 7, así que tengo un buen registro de esto para mirar.

En el caso de un bloqueo, obviamente no se registra nada entre el momento del bloqueo y el reinicio del sistema.

En el caso de un reinicio, es bastante obvio, ya que obtiene un registro de (casi) todo lo que systemd está haciendo para apagar el sistema.

Una de esas entradas de registro que probablemente no verá en ninguna otra circunstancia que no sea apagar o pasar al modo de usuario único es:

Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.

Puede reiniciar su propio sistema para ver qué se registra realmente.

No me gusta especialmente la respuesta, pero es una respuesta que obtuvimos de RH. Lo estoy publicando aquí en caso de que ayude a alguien más.

Una forma posible es buscar rsyslogden /var/log/messages. Un cierre elegante habría tenido exiting on signal 15. Un choque no lo haría.

tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'

Dos startlíneas consecutivas pueden indicar un bloqueo. Y un startseguido de un exitpuede indicar un reinicio.

Desafortunadamente, también podría dar malos resultados si rsyslogd se cae o se reinicia fuera de un reinicio / bloqueo.

Esto parece funcionar constantemente por "el apagado ordenado" ( shutdown, reboot, systemctl), así como "accidentes" (apagado, reinicio, echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

Una rebootlínea seguida de una shutdownlínea indica un "apagado correcto". Dos rebootlíneas indican un "bloqueo".