予期しない再起動の痕跡を記録から確認して原因を絞り込む手順

サーバーがいつの間にか再起動していた場合、原因の特定には「再起動直前に何が起きていたか」を記録から読み解く作業が欠かせません。この記事では、systemd 環境（RHEL 7以降・Ubuntu 16.04以降など）を対象に、ログから再起動の痕跡を確認して原因を絞り込む手順をまとめます。

再起動の種類と確認の方針

予期しない再起動の原因は大きく3種類に分けられます。

• カーネルパニック：カーネルが回復不能なエラーを検出し、自動的に再起動した
• OOMキラー（Out of Memory）：メモリ不足でカーネルが重要なプロセスを強制終了し、連鎖的に再起動した
• 電源断・ハードウェア障害：ログが途中で途切れ、正常なシャットダウンのシーケンスが記録されていない

原因の種類によって確認すべきログが異なります。まず「どの種類か」を大まかに絞り込んでから詳細を追うと、調査が効率よく進みます。

起動履歴の一覧で再起動のタイミングを把握する

systemd のジャーナルには起動ごとにブート ID が割り当てられており、過去の起動履歴を一覧で確認できます。

journalctl --list-boots

次のような出力が得られます（想定例）。

-3 a1b2c3... Thu 2026-11-05 10:00:00 JST—Thu 2026-11-05 23:58:00 JST
-2 d4e5f6... Fri 2026-11-06 00:01:30 JST—Fri 2026-11-06 18:45:00 JST
-1 g7h8i9... Fri 2026-11-06 18:46:10 JST—Sat 2026-11-07 09:00:00 JST
 0 j0k1l2... Sat 2026-11-07 09:01:45 JST—now

「-1」が前回の起動、「0」が現在の起動を表します。前回の終了時刻と今回の開始時刻の間に不自然な空白があれば、その間に異常な再起動が発生した可能性があります。last reboot コマンドでも同様の履歴を確認できます。

last reboot | head -20

前回の起動ログから再起動直前の記録を確認する

起動番号が分かれば、その直前のログを絞り込めます。-b -1 で前回の起動分のログを表示し、末尾に何が記録されているかを確認します。

journalctl -b -1 --no-pager | tail -n 100

正常なシャットダウンであれば、末尾に systemd-shutdown や Reached target Shutdown といったメッセージが記録されています。これらが見当たらず、ログが突然途切れている場合は、電源断またはカーネルパニックの可能性が高まります。

カーネルパニックが発生した場合は、次のキーワードでログを検索すると痕跡を見つけやすくなります。

journalctl -b -1 | grep -E "Kernel panic|BUG:|Call Trace|Oops"

OOMキラーが動作した場合は以下のキーワードが記録されます。

journalctl -b -1 | grep -i "oom\|out of memory\|killed process"

カーネルメッセージとハードウェアエラーを確認する

電源断を除くほとんどの異常再起動では、カーネルが何らかのメッセージを残しています。dmesg は現在の起動分しか表示しないため、前回分のカーネルログは journalctl 経由で確認します。

journalctl -b -1 -k

オプション -k はカーネルメッセージだけに絞り込みます。ハードウェア障害が原因の場合、MCE（Machine Check Exception）に関するメッセージが記録されていることがあります。

journalctl -b -1 -k | grep -i "mce\|hardware error\|edac\|corrected\|uncorrected"

MCEメッセージが大量に出ている場合はメモリやCPUの物理障害が疑われるため、ハードウェアベンダーへの確認が必要になります。

電源断を疑う場合の確認ポイント

ログが何の予兆もなく途切れている場合は、電源断が最有力候補となります。以下の点を追加で確認してください。

• ファイルシステムのダーティフラグ：次回起動時に fsck が自動的に走っていれば、ログに記録が残ります。journalctl -b 0 | grep -i fsck で確認できます
• UPSや電源監視ツールのログ：apcupsd や nut を使っている場合は、それぞれのログファイルも確認します
• 稼働時間の不連続性：last reboot の出力で、前回の起動から終了までの時間が極端に短い場合は強制終了のサインです

よくあるつまずきと注意点

journalctl のログが残っていない：デフォルトでは journald のログがメモリ上にのみ保持され、再起動すると消える設定になっているディストリビューションがあります。/etc/systemd/journald.conf の Storage= が volatile になっている場合、永続化されません。次のように変更して journald を再起動すると、以降のログが /var/log/journal/ に保存されます。

# /etc/systemd/journald.conf
[Journal]
Storage=persistent

systemctl restart systemd-journald

カーネルパニックのログが残らない：カーネルパニック時にはディスクへのフラッシュが間に合わないことがあります。重要なサーバーでは kdump（クラッシュダンプ）を設定しておくと、パニック時のカーネルメモリイメージを別領域に保存でき、より詳細な原因調査が可能になります。

タイムゾーンのずれに注意：journalctl はシステムのタイムゾーンで時刻を表示します。複数のサーバーのログを突き合わせる際は、タイムゾーンの設定が揃っているかをあらかじめ確認しておくと、ログの時系列を誤読するリスクを減らせます。timedatectl コマンドで現在のタイムゾーン設定を確認できます。