RHEL7でクラッシュと再起動をどのように区別できますか?


9

RHEL7サーバーがsystemctl(または再起動/シャットダウンエイリアス)経由で再起動されたかどうか、またはサーバーがクラッシュしたかどうかを判断する方法はありますか?事前にシステム化されていることは、でかなり簡単に判断できましたlast -x runlevelが、RHEL7ではそれほど明確ではありません。

回答:


3

これを行う方法は複数ありますが、考えられる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)独自のサービスユニットを作成する

あなたがそれをあなたが望むものに合わせることができるので、これは私見最良のアプローチです。これを行う方法は無数にあります。これが今作ったものです。この次のサービスはシャットダウン時にのみ実行されます。

[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

そのような良好な出力が得られれば、明らかにシステムは正常にシャットダウンされました。とは言っても、悪いことが起こったとき(システムがクラッシュしたとき)は、私の経験ではそれほど信頼できません。インデックスが奇妙になることがあります。


7

おかしい、私は昨夜たまたまCentOS 7システムをリブートしたので、これだけの良いログを見ることができます。

クラッシュの場合、クラッシュの時刻とシステムの再起動の間に何も記録されません。

再起動の場合、systemdがシステムをシャットダウンするために行っている(ほぼ)すべてのログを取得するので、それはかなり明白です。

シャットダウンするか、シングルユーザーモードに移行する以外の状況では表示されない可能性が高いログエントリの1つは、次のとおりです。

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

自分のシステムを再起動して、実際に何がログに記録されているかを確認できます。


1
CentOS 7はこれを記録し、RHEL 7は記録しないと思いますか?これが、CentOS(およびFedora)のログで確認されたものに基づく最初のアプローチでした。RHEL7でテストしたとき、サイコロはありません。
kwb 2016

1
@kwb RHEL 7.2システムを調べた後、そうだと思います。実際、ログに記録されるべき多くのものがログに記録されていないようです。それに対して私が言えることは、WTF?
マイケルハンプトン

何について話しているのかわからない。RHEL 7.0-7.2のsystemdはStopping Multi-User SystemおよびStopped target Multi-User Systemメッセージを生成します。
rsaw 2016

@rsawメッセージが生成されることは十分承知しています。問題は、それらがジャーナルに表示されないことです。
マイケルハンプトン

@MichaelHamptonジャーナルはデフォルトでは永続的ではありません。ユーザーが、mkdir /var/log/journalまたはで明示的に設定Storage=persistentしない限り、現在のブートのログのみを表示できます/etc/systemd/journald.conf。別の回答を投稿しました。
rsaw 2016

5

私は特に答えは好きではありませんが、RHから得た答えです。他の人を助けるためにここに投稿します。

可能な方法の1つは、でgrepを実行rsyslogdすること/var/log/messagesです。正常なシャットダウンにはがありexiting on signal 15ます。クラッシュはしませんでした。

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

2つの連続したstart行がクラッシュを示している可能性があります。のstart後にが続くexit場合は、再起動を示している可能性があります。

残念ながら、rsyslogdがダウンしたり、リブート/クラッシュの外で再起動したりすると、悪い結果をもたらす可能性があります。


悪いプレイRed Hat。exiting on signal 15再起動以外にも同じ結果になる他の動作があります。正常でservice rsyslog restartも、メッセージexiting on signal 15messageになります。
Stefan Lasiewski 16

これは有効な回答ですが、Red Hatのテクニカルサポートで働いている人としては、私はそうではありませんでした。私の答えを見てください。
rsaw 2016

1

これは、「正常な停止」のために一貫して動作しているようです(shutdownrebootsystemctl)だけでなく、「クラッシュ」(電源オフ、リセット、などecho c > /proc/sysrq-trigger):

last -x | grep 'reboot\|shutdown'

reboot続く行shutdownの行は、「正常なシャットダウン」を示しています。2 reboot行は「クラッシュ」を示します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.