Risposte:
C'è più di un modo per farlo, ma tratterò i 4 migliori che mi vengono in mente. (EDIT: ho pubblicato una versione ripulita di questo come articolo pubblico su redhat.com. Vedi: Come distinguere tra un arresto anomalo e un riavvio grazioso in RHEL 7. )
auditd è fantastico. Puoi vedere tutti i diversi eventi che registra controllando ausearch -m. A proposito del problema attuale, registra l'arresto del sistema e l'avvio del sistema, quindi è possibile utilizzare il comando ausearch -i -m system_boot,system_shutdown | tail -4. Se questo riporta un SYSTEM_SHUTDOWN seguito da un SYSTEM_BOOT , tutto va bene; tuttavia, se riporta 2 righe SYSTEM_BOOT di seguito, chiaramente il sistema non si è arrestato correttamente, come nell'esempio seguente:
[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'
Come sopra, ma con il semplice last -n2 -x shutdown rebootcomando. Esempio di arresto anomalo del sistema:
[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 dove il sistema ha avuto un riavvio grazioso:
[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)
Questo è l'IMHO l'approccio migliore perché puoi adattarlo a quello che vuoi. Ci sono milioni di modi per farlo. Eccone uno che ho appena inventato. Il prossimo servizio viene eseguito solo allo spegnimento.
[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.
Quindi, all'avvio del sistema, questo servizio successivo verrà avviato solo se esiste il file creato dal servizio di arresto sopra riportato.
[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.
Quindi, in qualsiasi momento, posso verificare se l'avvio precedente è stato eseguito dopo un arresto regolare systemctl is-active check_graceful, ad esempio:
[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 dopo un arresto ingrato:
[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.
Vale la pena ricordare che se si configura systemd-journalddi mantenere un diario persistente, è quindi possibile utilizzare journalctl -b -1 -nper guardare le ultime (10 per impostazione predefinita) righe dell'avvio precedente ( -b -2è l'avvio precedente, ecc.). Esempio in cui il sistema si è riavviato correttamente:
[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
Se si ottiene un buon output in questo modo, è chiaro che il sistema è stato spento correttamente. Detto questo, non è super affidabile nella mia esperienza quando accadono cose brutte (crash del sistema). A volte l'indicizzazione diventa strana.
Divertente, mi è capitato di riavviare un sistema CentOS 7 la scorsa notte, e quindi ho un bel registro di questo solo da guardare.
In caso di crash, ovviamente non viene registrato nulla tra l'ora del crash e il riavvio del sistema.
Nel caso di un riavvio, è abbastanza ovvio, poiché si ottiene un registro di (quasi) tutto ciò che systemd sta facendo per arrestare il sistema.
Una di queste voci di registro che probabilmente non vedrai in alcuna circostanza diversa dalla chiusura o dalla modalità utente singolo è:
Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.
Puoi riavviare il tuo sistema per vedere cosa viene effettivamente registrato.
Stopping Multi-User Systeme Stopped target Multi-User System.
mkdir /var/log/journalo esplicitamente impostato Storage=persistentin /etc/systemd/journald.conf. Ho pubblicato una risposta separata.
Non mi piace particolarmente la risposta, ma è una risposta che abbiamo ricevuto da RH. Lo sto postando qui nel caso in cui aiuti qualcun altro.
Un modo possibile è quello di grep per rsyslogda /var/log/messages. Un arresto grazioso avrebbe exiting on signal 15. Un incidente no.
tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'
Due startrighe consecutive possono indicare un arresto anomalo. E un startseguito da un exitpuò indicare un riavvio.
Sfortunatamente potrebbe anche dare risultati negativi se rsyslogd si interrompe o viene riavviato al di fuori di un riavvio / arresto anomalo.
exiting on signal 15oltre al riavvio. Una normale service rsyslog restartrisulta anche nel exiting on signal 15messaggio.
Questo sembra funzionare costantemente per "arresti graziosi" ( shutdown, reboot, systemctl), così come "crash" (spegnimento, reset, echo c > /proc/sysrq-trigger):
last -x | grep 'reboot\|shutdown'
Una rebootlinea seguita da una shutdownlinea indica un "arresto graduale". Due rebootlinee indicano un "arresto".