มีวิธีการตรวจสอบว่าเซิร์ฟเวอร์ RHEL7 ถูกรีบูทผ่าน systemctl (หรือรีบูต / ปิดนามแฝง) หรือไม่หรือว่าเซิร์ฟเวอร์ล้มเหลวหรือไม่ Pre-systemd นี้ค่อนข้างง่ายต่อการตรวจสอบlast -x runlevelแต่ RHEL7 ไม่ชัดเจนนัก

มีมากกว่าหนึ่งวิธีในการทำสิ่งนี้ แต่ฉันจะกล่าวถึงสิ่งที่ดีที่สุด 4 อย่างที่ฉันคิดได้ (แก้ไข: ฉันเผยแพร่รุ่นทำความสะอาดนี้เป็นบทความสาธารณะใน redhat.com ดู: วิธีแยกแยะความผิดพลาดและการรีบูทที่สวยงามใน RHEL 7 )

(1) บันทึกการตรวจสอบ

auditd เป็นที่น่าอัศจรรย์ คุณสามารถดูทั้งหมดเหตุการณ์ต่าง ๆ 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) สร้างหน่วยบริการของคุณเอง

นี่คือวิธีการที่ดีที่สุดสำหรับ IMHO เพราะคุณสามารถปรับให้เข้ากับสิ่งที่คุณต้องการ มีล้านวิธีในการทำเช่นนี้ นี่คือสิ่งที่ฉันเพิ่งทำ บริการต่อไปนี้จะทำงานเมื่อปิดเครื่องเท่านั้น

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

เป็นมูลค่าการกล่าวขวัญว่าถ้าคุณกำหนดค่า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 เมื่อคืนดังนั้นฉันจึงมีบันทึกที่ดีสำหรับเรื่องนี้เพื่อดู

ในกรณีที่เกิดความผิดพลาดจะไม่มีการบันทึกระหว่างเวลาที่ระบบหยุดทำงานและระบบรีสตาร์ท

ในกรณีของการรีบูทมันค่อนข้างชัดเจนเนื่องจากคุณได้รับบันทึกของ (เกือบ) ทุกอย่างที่ systemd กำลังทำเพื่อปิดระบบ

รายการบันทึกดังกล่าวหนึ่งรายการที่คุณไม่น่าจะเห็นในทุกสถานการณ์นอกเหนือจากการปิดเครื่องหรือไปที่โหมดผู้ใช้คนเดียวคือ:

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

คุณสามารถรีบูตระบบของคุณเองเพื่อดูว่าอะไรได้รับการบันทึก

ฉันไม่ชอบคำตอบเป็นพิเศษ แต่เป็นคำตอบที่เราได้รับจาก RH ฉันโพสต์ไว้ที่นี่ในกรณีที่ช่วยเหลือคนอื่น

วิธีการหนึ่งที่เป็นไปได้คือการ grep สำหรับใน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บรรทัดแสดงว่า "ผิดพลาด"