Чи є спосіб визначити, чи був перезавантажений сервер RHEL7 через systemctl (або псевдоніми перезавантаження / вимкнення), чи сервер зазнав аварії? Попередньо систематизовано це було досить легко визначити last -x runlevel, але з RHEL7 це не так однозначно.

Існує більше ніж один спосіб зробити це, але я висвітлю 4 найкращих, про які я можу придумати. (EDIT: Я опублікував очищену версію цього як публічну статтю на redhat.com. Див.: Як розрізнити аварію та витончене перезавантаження в RHEL 7. )

(1) журнали аудиту

аудит дивовижний. Ви можете побачити всі різні події, які він реєструє, перевіривши ausearch -m. Що стосується наявної проблеми, вона реєструє відключення системи та завантаження системи, тому ви можете використовувати команду ausearch -i -m system_boot,system_shutdown | tail -4. Якщо це повідомляє про SYSTEM_SHUTDOWN, а за ним SYSTEM_BOOT , все добре; однак, якщо вона повідомляє про 2 ряди SYSTEM_BOOT підряд, тоді явно система не вимкнеться витончено, як у наступному прикладі:

[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) останній -x

Те саме, що вище, але з простою last -n2 -x shutdown rebootкомандою. Приклад, коли система вийшла з ладу:

[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)    

Або там, де система мала витончене перезавантаження:

[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) створити власний блок обслуговування

Це найкращий підхід ІМХО, оскільки ви можете налаштувати його на все, що завгодно. Є мільйон способів зробити це. Ось я тільки що склав. Наступна послуга працює лише при відключенні.

[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.

Потім, коли система завантажиться, наступна служба запуститься лише за наявності файлу, створеного вищезгаданою службою відключення.

[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.

Тому в будь-який момент я можу перевірити, чи було попереднє завантаження після витонченого відключення, виконавши systemctl is-active check_graceful, наприклад:

[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.

Або ось після несамовитого відключення:

[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) журнал

Варто згадати, що якщо ви налаштовуєте systemd-journaldзберігати постійний журнал, ви можете скористатися journalctl -b -1 -nдля перегляду останніх (10 за замовчуванням) рядків попереднього завантаження ( -b -2це завантаження до цього тощо). Приклад, коли система граціозно перезавантажилась:

[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

Якщо ви отримаєте хороший вихід таким чином, тоді явно система була вимкнено витончено. Однак, на мій досвід, це не дуже надійно, коли трапляються погані речі (збої в системі). Іноді індексація стає дивною.

Смішно, я щойно трапився перезавантажити систему CentOS 7 минулої ночі, і тому я маю приємний журнал лише цього.

У випадку аварії, очевидно, нічого не реєструється між часом аварії та перезавантаженням системи.

У випадку перезавантаження це досить очевидно, оскільки ви отримуєте журнал (майже) всього, що система робить, щоб вимкнути систему.

Один з таких записів журналу, який ви, швидше за все, не побачите за будь-яких обставин, окрім вимкнення або переходу в режим одного користувача:

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

Ви можете перезавантажити власну систему, щоб побачити, що насправді реєструється.

Я не особливо люблю відповідь, але це відповідь, яку ми отримали від RH. Я розміщую його тут на випадок, якщо це допомагає комусь іншому.

Одним з можливих способів є виокремити інформацію rsyslogdв /var/log/messages. Витончене відключення було б exiting on signal 15. Аварії не буде.

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

Два послідовні startлінії можуть вказувати на збій. А startподальше повідомлення exitможе вказувати на перезавантаження.

На жаль, це також може дати погані результати, якщо rsyslogd знизиться або перезапуститься поза перезавантаженням / збоєм.

Це схоже на роботу послідовно для «витончених зупинок» ( shutdown, reboot, systemctl), а також «аварія» (відключення живлення, скидання, echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

rebootЛінії слід shutdownлінії вказує на «завершення» витончений. Два rebootрядки вказують на "збій".