ホーム テクノロジー LINUX Linuxの再起動理由を見つける方法?

Linuxの再起動理由を見つける方法?


Linux システムが計画外の方法で、または不明な明白な理由により再起動されたことがよくあります。根本原因を見つけて解決することは、そのような問題の再発を防ぎ、計画外のダウンタイムを回避するのに役立ちます。

何が再起動を引き起こしたのかを調べる方法はいくつかあります。この記事では、これらの方法と、Linux システムで利用可能なユーティリティとログを利用してそのようなシナリオのトラブルシューティングを行う方法について説明します。

再起動時間を検査する

whoおよびlastコマンドを使用して、システムの再起動がいつ行われたかを確認できます。

 $ who -b
system boot 2021-02-13 20:51

$ last -x | head | tac
abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in
$

システムメッセージを確認する

診断したい再起動とシステム メッセージをさらに関連付けることができます。

CentOS/RHEL システムの場合、ログは/var/log/messagesにあり、Ubuntu/Debian システムの場合、ログは/var/log/syslogに記録されます。 tailコマンドまたはお気に入りのテキスト エディタを使用するだけで、特定のデータをフィルタリングしたり検索したりできます。

以下のログから推測できるように、このようなエントリは、管理者または root ユーザーによって開始されたシャットダウン/再起動を示唆しています。これらのメッセージは、OS の種類や再起動/シャットダウンのトリガー方法によって異なりますが、毎回原因を正確に特定できるほど明確ではない場合でも、システム ログを参照すると有益な情報が常に見つかります。

 Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5
Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root.
Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root.
Feb 13 20:04:09 centos7vm systemd-logind: System is powering down.
Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket.
Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.

システム ログをフィルタリングするために使用できるコマンドの 1 つを以下に示します。

 sudo grep -iv ': starting\|kernel: .*: Power Button\|watching system buttons\|Stopped Cleaning Up\|Started Crash recovery kernel' \
  /var/log/messages /var/log/syslog /var/log/apcupsd* \
  | grep -iw 'recover[a-z]*\|power[a-z]*\|shut[a-z ]*down\|rsyslogd\|ups'

キャプチャされたイベントは必ずしも特定的であるとは限りません。システムの電源オフやクラッシュにつながる可能性のある警告やエラーの兆候を示すイベントを常に追跡してください。

Auditd ログを確認する

auditdを備えたシステムの場合、 ausearchツールを使用してさまざまなイベントをチェックするのに最適な場所です。以下のコマンドを使用して、監査ログの最後の 2 つのエントリを確認します。

 $ sudo ausearch -i -m system_boot,system_shutdown | tail -4

これにより、最近の 2 回のシャットダウンまたは再起動が報告されます。これによりSYSTEM_SHUTDOWN報告され、その後にSYSTEM_BOOT報告された場合は、すべてが正常であるはずです。ただし、 SYSTEM_BOOT行が 2 行続けて報告される場合、またはSYSTEM_BOOT行が 1 行だけ報告される場合は、システムが正常にシャットダウンされなかった可能性があります。通常の出力は次のようになります。

 $ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 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(Saturday 13 February 2021 A.368:8) : pid=622 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 つの連続するSYSTEM_BOOTメッセージがリストされています。これは、システム ログと関連付ける必要がありますが、不正なシャットダウンを示している可能性があります。

 $ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 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(Saturday 13 February 2021 A.368:8) : pid=622 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'
$

systemd ジャーナルを分析する

ディスク上に永続的なジャーナルを保持するには、永続的な systemd ジャーナルが必要です。そうしないと、再起動時にログが保持されません。このために、 /etc/systemd/journald.confを変更するか、以下のコマンドを使用してディレクトリを自分で作成することができます。

 $ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald

完了したら、必要に応じてシステムを再起動して、ジャーナルに複数の再起動エントリをキャプチャできますが、これは必須ではありません。

以下のコマンドを使用して、ログに記録されたブートをジャーナルからリストします。

 $ journalctl --list-boots

私のサーバー上の出力は次のとおりです。

 $ journalctl --list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST
 -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST
 -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST
 -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST
 -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST
 -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST
 -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST
 -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST
 -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST
 -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST
  0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
$

ご覧のとおり、いくつかのブーツがリストされています。特定の再起動をさらに分析するには、次を使用します。

 $ journalctl -b {num} -n

ここで、 {num}journalctl --list-bootsコマンドの最初の列で指定されたインデックスになります。

 $ journalctl -b -1 -n
-- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. --
Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped
$

上記の出力でジャーナルに記録されたメッセージを観察し、異常がある場合はそれを追跡できます。

結論

単一のコマンドまたは単一のログ ファイルを使用して Linux 再起動の原因を特定できるとは限りません。そのため、システム関連のイベントをキャプチャするコマンドとログを知っておくと常に便利で、根本原因を見つけるのに必要な時間を短縮できます。

上記の例は、トラブルシューティングを開始するための出発点となります。このようなツールとログを組み合わせて使用​​すると、何が起こったのか、システムがどのように再起動されたのかを確実に知ることができます。

次に、Linux 用の軽量監視ソフトウェアをいくつか探します。

「 Linuxの再起動理由を見つける方法?」についてわかりやすく解説!絶対に観るべきベスト2動画

Nobara38(Linux)をVirtualBox7にインストール
Linux って意味あるの?改めて Linux の存在意義を考えてみました。