Jawaban:
Ada lebih dari satu cara untuk melakukan ini, tetapi saya akan membahas 4 yang terbaik yang dapat saya pikirkan. (EDIT: Saya menerbitkan versi pembersihan ini sebagai artikel publik di redhat.com. Lihat: Bagaimana membedakan antara crash dan reboot yang anggun di RHEL 7. )
auditd luar biasa. Anda dapat melihat semua peristiwa berbeda yang dicatat dengan memeriksa ausearch -m
. Berhubungan dengan masalah yang dihadapi, ia mencatat shutdown sistem dan boot sistem, sehingga Anda dapat menggunakan perintah ausearch -i -m system_boot,system_shutdown | tail -4
. Jika ini melaporkan SYSTEM_SHUTDOWN diikuti oleh SYSTEM_BOOT , semuanya baik-baik saja; namun, jika ia melaporkan 2 baris SYSTEM_BOOT berturut-turut, maka jelas sistem tidak mematikan dengan anggun, seperti dalam contoh berikut:
[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'
Sama seperti di atas, tetapi dengan last -n2 -x shutdown reboot
perintah sederhana . Contoh di mana sistem macet:
[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)
Atau ketika sistem melakukan boot ulang dengan anggun:
[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)
Ini adalah IMHO pendekatan terbaik karena Anda dapat menyesuaikannya dengan apa pun yang Anda inginkan. Ada sejuta cara untuk melakukan ini. Ini yang baru saya buat. Layanan selanjutnya ini hanya berjalan pada saat shutdown.
[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.
Kemudian ketika sistem melakukan booting, layanan berikutnya hanya akan dimulai jika file yang dibuat oleh layanan shutdown di atas ada.
[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.
Jadi pada waktu tertentu saya dapat memeriksa apakah boot sebelumnya dilakukan setelah melakukan shutdown dengan anggun systemctl is-active check_graceful
, misalnya:
[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.
Atau di sini setelah shutdown tidak berterima:
[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.
Perlu disebutkan bahwa jika Anda mengkonfigurasi systemd-journald
untuk membuat jurnal yang persisten, Anda dapat menggunakan journalctl -b -1 -n
untuk melihat beberapa baris terakhir (10 secara default) dari boot sebelumnya ( -b -2
adalah boot sebelum itu, dll). Contoh di mana sistem reboot dengan anggun:
[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
Jika Anda mendapatkan output yang baik seperti itu, maka jelas sistemnya dimatikan dengan anggun. Yang mengatakan, itu tidak bisa diandalkan dalam pengalaman saya ketika hal-hal buruk terjadi (sistem crash). Terkadang pengindeksan menjadi aneh.
Lucu, saya baru saja me-reboot sistem CentOS 7 tadi malam, dan jadi saya punya catatan bagus untuk dilihat.
Dalam kasus crash, jelas tidak ada yang dicatat antara waktu crash dan sistem restart.
Dalam kasus reboot, sangat jelas, ketika Anda mendapatkan log (hampir) semua yang dilakukan systemd untuk mematikan sistem.
Salah satu entri log seperti itu yang tidak akan Anda lihat dalam keadaan apa pun selain mematikan atau beralih ke mode pengguna tunggal adalah:
Jul 13 01:27:55 yaungol systemd: Stopped target Multi-User System.
Anda dapat mem-boot ulang sistem Anda sendiri untuk melihat apa yang sebenarnya dicatat.
Stopping Multi-User System
dan Stopped target Multi-User System
pesan.
mkdir /var/log/journal
atau secara eksplisit Storage=persistent
masuk /etc/systemd/journald.conf
. Saya memposting jawaban terpisah.
Saya tidak terlalu suka jawabannya, tetapi ini adalah jawaban yang kami dapatkan dari Kesehatan Reproduksi. Saya mempostingnya di sini kalau-kalau itu membantu orang lain.
Salah satu cara yang mungkin adalah untuk grep untuk rsyslogd
di /var/log/messages
. Shutdown yang anggun akan terjadi exiting on signal 15
. Kecelakaan tidak akan terjadi.
tac /var/log/messages | grep 'rsyslogd.*start\|rsyslogd.*exit'
Dua start
baris berturut-turut dapat mengindikasikan crash. Dan start
diikuti oleh tanda exit
mungkin menunjukkan reboot.
Sayangnya itu juga bisa memberikan hasil yang buruk jika rsyslogd turun atau di-restart di luar reboot / crash.
exiting on signal 15
selain reboot. Normal service rsyslog restart
juga menghasilkan pesan exiting on signal 15
pesan.
Hal ini tampaknya bekerja secara konsisten untuk "shutdowns anggun" ( shutdown
, reboot
, systemctl
) serta "crash" (power off, reset, echo c > /proc/sysrq-trigger
):
last -x | grep 'reboot\|shutdown'
Sebuah reboot
garis diikuti oleh shutdown
garis menunjukkan "shutdown". Dua reboot
baris menunjukkan "crash".