在RHEL7上如何区分崩溃和重新启动?


10

有没有一种方法可以确定是否通过systemctl(或重新启动/关闭别名)重新启动了RHEL7服务器,或者该服务器是否崩溃了?预先last -x runlevel系统化,使用可以很容易确定,但是使用RHEL7尚不清楚。

Answers:


4

有多种方法可以做到这一点,但我将介绍我能想到的4种最佳方法。(编辑:我在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)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

如果获得这样的良好输出,则显然系统已正常关闭。就是说,当发生坏事(系统崩溃)时,根据我的经验,它并不是非常可靠。有时索引变得怪异。


8

有趣的是,我昨晚刚巧重启了CentOS 7系统,因此我有一个不错的日志可以查看。

在崩溃的情况下,显然在崩溃时间和系统重启之间没有任何记录。

在重新启动的情况下,这很明显,因为您会获得(几乎)systemd关闭系统所做的一切的日志。

除了关闭或进入单用户模式外,在任何情况下都不太可能看到的此类日志条目是:

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

您可以重新启动自己的系统以查看实际记录的内容。


1
您相信CentOS 7会记录此信息,而RHEL 7不会吗?那是我们最初基于CentOS(和Fedora)日志中看到的方法。当我们在RHEL7上进行测试时,没有骰子。
kwb

1
@kwb看完RHEL 7.2系统后,是的,我相信。实际上,似乎许多应记录的内容并未记录。我只能说的是:WTF?
迈克尔·汉普顿

不知道你们在说什么。RHEL 7.0-7.2中的systemd生成Stopping Multi-User SystemStopped target Multi-User System消息。
rsaw

@rsaw我们很清楚消息已生成。问题在于它们没有出现在日志中。
迈克尔·汉普顿

@MichaelHampton日志默认情况下不是持久性的。除非您进行了mkdir /var/log/journal明确设置Storage=persistent,否则您只能看到当前引导中的日志/etc/systemd/journald.conf。我发布了一个单独的答案。
rsaw

5

我不太喜欢这个答案,但这是我们从RH得到的答案。我将其张贴在这里,以防其他人使用。

一种可能的方法是grep for rsyslogdin /var/log/messages。一个正常的关机将有exiting on signal 15。崩溃不会。

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

start行连续可能表明发生了崩溃。并且start后跟exit可能表示重新启动。

不幸的是,如果rsyslogd出现故障或在重新启动/崩溃后重新启动,它也可能导致不良结果。


不好玩的红帽。exiting on signal 15除了重新启动以外,还有其他行为会导致相同的结果。正常service rsyslog restart也会导致出现exiting on signal 15消息。
Stefan Lasiewski,

这是一个有效的答案,但是作为从事Red Hat技术支持工作的人,这不是我想要的。看我的答案。
rsaw

1

这似乎工作始终为“正常关闭”( ,shutdownrebootsystemctl以及“崩溃”(断电复位,echo c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

一个reboot行后跟一个shutdown行表示“正常关机”。两reboot行表示“崩溃”。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.