Antworten:
Es gibt mehr als einen Weg, dies zu tun, aber ich werde die 4 besten behandeln, die mir einfallen. (BEARBEITEN: Ich habe eine bereinigte Version davon als öffentlichen Artikel auf redhat.com veröffentlicht. Siehe: Unterscheiden zwischen einem Absturz und einem ordnungsgemäßen Neustart in RHEL 7. )
auditd ist unglaublich. Sie können alle verschiedenen Ereignisse anzeigen, die protokolliert werden, indem Sie überprüfen ausearch -m. Entsprechend dem vorliegenden Problem werden das Herunterfahren des Systems und der Systemstart protokolliert, sodass Sie den Befehl verwenden können ausearch -i -m system_boot,system_shutdown | tail -4. Wenn dies ein SYSTEM_SHUTDOWN gefolgt von einem SYSTEM_BOOT meldet , ist alles in Ordnung ; Wenn jedoch 2 SYSTEM_BOOT- Zeilen hintereinander gemeldet werden, wurde das System eindeutig nicht ordnungsgemäß heruntergefahren, wie im folgenden Beispiel:
[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'
Wie oben, jedoch mit dem einfachen last -n2 -x shutdown rebootBefehl. Beispiel, bei dem das System abgestürzt ist:
[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)
Oder wo das System einen ordnungsgemäßen Neustart hatte:
[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)
Dies ist meiner Meinung nach der beste Ansatz, da Sie ihn auf alles zuschneiden können, was Sie wollen. Es gibt eine Million Möglichkeiten, dies zu tun. Hier ist eine, die ich gerade erfunden habe. Dieser nächste Dienst wird nur beim Herunterfahren ausgeführt.
[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.
Wenn das System dann startet, wird dieser nächste Dienst nur gestartet, wenn die vom obigen Abschaltdienst erstellte Datei vorhanden ist.
[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.
So kann ich jederzeit überprüfen, ob der vorherige Start nach einem ordnungsgemäßen Herunterfahren durchgeführt wurde, indem ich systemctl is-active check_gracefulz.
[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.
Oder hier ist nach einem unansehnlichen Herunterfahren:
[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.
Es ist erwähnenswert, dass Sie, wenn Sie systemd-journaldein dauerhaftes Journal führen, journalctl -b -1 -ndie letzten Zeilen (standardmäßig 10) des vorherigen Starts anzeigen können ( -b -2ist der Start davor usw.). Beispiel, bei dem das System ordnungsgemäß neu gestartet wurde:
[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
Wenn Sie so eine gute Ausgabe erhalten, wurde das System eindeutig ordnungsgemäß heruntergefahren. Trotzdem ist es meiner Erfahrung nach nicht besonders zuverlässig, wenn schlimme Dinge passieren (Systemabstürze). Manchmal wird die Indizierung komisch.
Komisch, ich habe gestern Abend zufällig ein CentOS 7-System neu gestartet, und deshalb habe ich ein schönes Protokoll darüber.
Im Falle eines Absturzes wird zwischen dem Zeitpunkt des Absturzes und dem Neustart des Systems offensichtlich nichts protokolliert.
Im Falle eines Neustarts ist dies ziemlich offensichtlich, da Sie ein Protokoll über (fast) alles erhalten, was systemd tut, um das System herunterzufahren.
Ein solcher Protokolleintrag, den Sie wahrscheinlich nur unter Herunterfahren oder Wechseln in den Einzelbenutzermodus sehen, ist:
Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.
Sie können Ihr eigenes System neu starten, um zu sehen, was tatsächlich protokolliert wird.
Stopping Multi-User Systemund Stopped target Multi-User System-Nachrichten.
mkdir /var/log/journaloder explizit Storage=persistentin /etc/systemd/journald.conf. Ich habe eine separate Antwort gepostet.
Ich mag die Antwort nicht besonders, aber es ist eine Antwort, die wir von RH bekommen haben. Ich poste es hier, falls es jemand anderem hilft.
Ein möglicher Weg ist, nach rsyslogdin zu suchen /var/log/messages. Ein würdevolles Herunterfahren hätte exiting on signal 15. Ein Absturz würde nicht.
tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'
Zwei aufeinanderfolgende startZeilen können auf einen Absturz hinweisen. Und ein startgefolgt von einem exitkann auf einen Neustart hinweisen.
Leider kann es auch zu schlechten Ergebnissen kommen, wenn rsyslogd ausfällt oder außerhalb eines Neustarts / Absturzes neu gestartet wird.
exiting on signal 15Neben einem Neustart gibt es noch andere Verhaltensweisen, die dazu führen . Ein Normal service rsyslog restartergibt auch die Nachricht exiting on signal 15Nachricht.
Dies scheint zu arbeiten konsequent für „Graceful Abschaltungen“ ( shutdown, reboot, systemctl) sowie „abstürzt“ (Ausschalten, Reset echo c > /proc/sysrq-trigger):
last -x | grep 'reboot\|shutdown'
Eine rebootZeile gefolgt von einer shutdownZeile zeigt ein "ordnungsgemäßes Herunterfahren" an. Zwei rebootZeilen zeigen einen "Absturz" an.