Linuxサーバーが突然再起動する時に確認すべきログ

運用中のLinuxサーバーが予告なく突然再起動するトラブルは、現場で非常に厄介です。 再起動後はサーバー自体が正常に見えるため、原因調査が後回しになりがちですが、放置すると再発します。

本記事では、Linuxサーバーが突然再起動した際に、どのログを・どの順番で確認すべきかを、実務の障害対応フローに沿って解説します。

まず最初に確認すべきこと

ログ調査に入る前に、以下を整理します。

• 再起動が発生した正確な時刻
• 単発か、定期的に発生しているか
• 手動操作・自動処理の有無

時刻が曖昧だとログ調査はほぼ不可能になります。 必ず監視アラートや外形監視の時刻を控えてから進めましょう。

確認すべきログの全体像

Linuxの突然再起動は、主に以下4系統に分類されます。

• OS・カーネル起因
• メモリ不足（OOM Killer）
• ハードウェア障害
• 手動／自動再起動

それぞれで確認すべきログが異なります。

① /var/log/messages（または syslog）

最優先で確認すべきログです。

less /var/log/messages

Debian系では以下の場合もあります。

less /var/log/syslog

確認ポイント：

• 再起動直前のエラーメッセージ
• kernel: 行の出力
• panic / error / fail の文字列

再起動直前でログが途切れている場合は、OSが強制的に落ちた可能性が高いです。

② OOM Killer（メモリ不足）の確認

Linuxではメモリが枯渇すると、OOM Killerが動作し、最悪の場合サーバーが再起動します。

grep -i oom /var/log/messages

以下のようなログがあればOOMが原因です。

• Out of memory
• Killed process xxxx

OOMが原因の場合、CPU高騰・大量アクセス・メモリリークが背景にあります。

③ カーネルパニックの確認

カーネルパニックは、Linuxが自力で動作継続できない致命的エラーです。

grep -i panic /var/log/messages

典型的なキーワード：

• kernel panic
• not syncing

カーネルパニックが出ている場合、OSバグ・ドライバ・HW障害の可能性が高くなります。

④ last / last reboot コマンド

再起動が誰かの操作なのかを切り分けるために必須です。

last reboot

last -x

確認ポイント：

• 再起動時刻
• shutdown / reboot コマンドの履歴

ここで記録が残っていれば、手動またはスクリプトによる再起動の可能性があります。

⑤ cron・自動処理の確認

意外と多いのが、cronに仕込まれた再起動処理です。

crontab -l

ls /etc/cron.*

過去に設定されたメンテナンス用ジョブが残っているケースもあります。

⑥ ハードウェア障害ログ（dmesg）

HW障害や仮想基盤起因の場合、dmesgに痕跡が残ることがあります。

dmesg -T

確認すべき内容：

• CPU Error
• Memory Error
• I/O Error

物理サーバーではECCエラー、仮想環境ではホスト側障害の可能性も考慮します。

⑦ クラウド・仮想環境特有の確認点

クラウド（Azure / AWSなど）では、以下も確認します。

• プラットフォームメンテナンス
• 強制再起動イベント
• スケール設定・自動復旧

OSログに何も残らない場合、基盤側イベントの可能性が高いです。

原因別の典型パターン整理

原因	特徴
OOM Killer	メモリ関連ログあり
カーネルパニック	panicログで終了
HW障害	dmesgにError
手動再起動	lastコマンドに履歴
基盤障害	OSログがほぼ残らない

再発防止のためにやるべきこと

• メモリ・CPU監視の強化
• ログ保存期間の延長
• 再起動検知アラートの設定
• 原因が不明な場合はベンダー問い合わせ

まとめ

Linuxサーバーの突然再起動は、必ず何らかの痕跡が残ります。

重要なのは、

• 時刻を正確に押さえる
• messages → OOM → panic → 操作履歴の順で調査

感覚や推測ではなく、ログベースで原因を特定することで、再発防止につながります。

突然再起動は「事故」ではなく「兆候」です。 必ず原因を突き止め、次に備えましょう。