カーネルパニックとwatchdog・ハング検出

パニック・Oops・BUGの違いを区別する

「カーネルが落ちた」という言い方は曖昧で、内部では重大度の異なる複数の経路が走っています。まず3つを正確に分けます。

パニック（panic） は、カーネルが「これ以上安全に実行を続けられない」と判断したときに呼ぶ最終手段です。panic() 関数は全 CPU を停止させ、コンソールにメッセージとスタックトレースを出し、設定に従って再起動するかその場で固まります。回復は一切試みません。ルートファイルシステムをマウントできない、致命的なハードウェアエラー、明示的に致命と判断した内部矛盾などで発生します。

Oops は、カーネル空間で発生した回復可能かもしれない異常（典型は NULL ポインタ参照や不正アドレスアクセスによるページフォルト）に対する反応です。カーネルはエラー情報（レジスタ、スタック、RIP/PC）をダンプし、問題を起こしたプロセスだけを kill して延命を試みます。ただし重要なのは、Oops が起きた時点でカーネルの内部状態は すでに壊れている可能性が高い という点です。ロックを保持したまま死んだ、メモリ構造が中途半端、といった状態が残ると、その後の動作は信用できません。

BUG / BUG_ON は、カーネルコードが「ここには絶対に到達しないはず」という不変条件を表明（アサーション）する仕組みです。BUG_ON(cond) は条件成立時に意図的に Oops 相当の処理を起こし、WARN_ON はスタックトレースを出すだけで実行を続けます。BUG はバグの早期発見が目的で、検出された矛盾はそのまま放置するより止めた方が安全だという設計思想に基づきます。

ハングはなぜ「検出」が必要か

パニックや Oops は カーネル自身が異常を自覚して 能動的に報告する経路です。やっかいなのは、カーネルが 何も報告できないまま固まる ケース、すなわちハング（ロックアップ）です。デッドロック、無限ループ、割り込みを禁止したままの長時間処理などでは、カーネルは「自分が止まっている」ことを認識できません。止まっている主体に自己申告は期待できないため、外部から周期的に生存を確認する監視機構＝ウォッチドッグが必要になります。

ウォッチドッグの基本原理は共通で、「正常なら周期的に行われるはずの動作」が一定時間途絶えたら異常と見なす、というタイムアウト検出です。Linux では止まり方の深さによって3種類の検出器が使い分けられます。

ソフトロックアップ検出（スケジューラに戻らない）

ソフトロックアップ は、ある CPU がカーネルモードで長時間ループし続け、スケジューラに制御を戻さない 状態です。割り込み自体は通っている（タイマ割り込みは入る）ものの、その CPU 上では他のタスクが一切走れません。

検出には各 CPU で動く高優先度のカーネルスレッド（watchdog/N）を使います。仕組みはこうです。

1. 各CPUにタイマ割り込みベースの周期処理を仕込む
2. その割り込みハンドラがCPUごとのタイムスタンプを更新する
3. watchdogスレッドが定期的に起きて自分のタイムスタンプを進める
4. タイムスタンプが一定時間（既定はwatchdog_threshの2倍）進まなければ
   = そのCPUがスケジューラに戻っていない → ソフトロックアップと判定

ここでの肝は タイマ割り込みは生きている 点です。割り込みハンドラがタイムスタンプを刻めるからこそ「割り込みは入るがスレッドが走れない」という状態を検出できます。閾値は kernel.watchdog_thresh（既定10秒）で調整し、ソフトロックアップはその2倍（既定で20秒）途絶えた時点で判定されます。検出時にはスタックトレースを出して原因の特定を助けます。タイマ割り込みの基盤は 高分解能タイマとカーネルの時間管理 を参照してください。

ハードロックアップ検出（割り込みすら通らない）

ハードロックアップ はさらに深刻で、その CPU が 割り込みを禁止したまま ループに陥り、タイマ割り込みすら届かない状態です。ソフトロックアップ検出はタイマ割り込みに依存しているため、この状況では検出器そのものが動けません。割り込みが止まっている主体を、割り込み経由で監視することはできないからです。

そこで使うのが NMI（Non-Maskable Interrupt、マスク不能割り込み） です。NMI は通常の割り込み禁止（ローカル割り込みフラグのクリア）では遮断できない特別な割り込みで、CPU がどれだけ割り込みを止めていても強制的に入ります。NMI ウォッチドッグは次の発想で動きます。

1. PMU（性能監視ユニット）のハードウェアカウンタを使い、
   一定間隔でNMIを発生させるよう設定する
2. NMIハンドラがCPUごとの「タイマ割り込みカウンタ」を確認する
3. 通常のタイマ割り込みが進んでいれば正常
4. NMIは入るのにタイマ割り込みが長時間進んでいない
   = 通常割り込みが遮断されている → ハードロックアップと判定

NMI はマスク不能なので、対象 CPU が割り込み禁止でループしていても確実に割り込んでスタックを採取できます。「マスク可能割り込み（タイマ）が止まったことを、マスク不能割り込み（NMI）から観測する」という二経路の非対称性が、この検出の本質です。NMI と APIC・PMU の関係は 割り込みコントローラの仕組み（APIC・GIC・MSI-X） を、割り込み処理の文脈は 割り込み処理の二段構え（上半分/下半分） を参照してください。

hung task watchdog（D状態のタスクを監視）

3つめは少し毛色が違います。hung task watchdog は、CPU の暴走ではなく、個々のタスクが長時間まったく進まない ことを検出します。対象は主に TASK_UNINTERRUPTIBLE（D 状態）、つまり I/O 完了などを待って割り込み不能スリープに入ったまま長時間起きてこないタスクです。

khungtaskd というカーネルスレッドが定期的に全タスクを走査し、D 状態のまま一定時間（kernel.hung_task_timeout_secs、既定120秒）スケジューリングされていないタスクを見つけると警告を出します。これはデッドロック、ストレージや NFS の応答停止、ドライバのバグなどで「待ち続けて返ってこない」状況を炙り出すための機構です。CPU は他のタスクを普通に動かせている点が、ソフト／ハードロックアップとの決定的な違いです。

panic後の動作：再起動とダンプ

パニックが起きたとき、ただ固まるか自動で再起動するか、原因を残すかは設定で決まります。重要なパラメータと動作を押さえます。

自動再起動 は kernel.panic パラメータ（panic_timeout）で制御します。値が 0 なら再起動せずその場で停止（コンソールでメッセージを保全。デバッグ向き）、正の値 N なら N 秒後に再起動、負の値なら即時再起動です。無人運用のサーバーでは正の値にして自動復旧させるのが一般的です。

カーネルダンプ（kdump） は、パニック時のメモリ全体（または必要部分）を保存して事後解析を可能にする仕組みです。鍵となるのが kexec で、これは「現在のカーネルから、再起動を経ずに別のカーネルを直接起動する」機構です。kdump は次の流れで動きます。

1. 通常起動時に、ダンプ採取用の「クラッシュカーネル」を
   メモリの予約領域（crashkernel=...で確保）にロードしておく
2. パニック発生 → kexecで予約領域のクラッシュカーネルへ切り替える
3. クラッシュカーネルは、汚染された元カーネルのメモリを
   /proc/vmcoreとして読み出せる状態で起動する
4. そのメモリイメージをディスクやネットワークへ保存（vmcore）
5. 保存完了後に通常再起動する

この設計の妙は、壊れた元カーネルのメモリを上書きせずに保存する ために、別の予約領域で動く独立したカーネルを使う点です。元カーネルは信用できない状態なので、自分自身でダンプを書こうとすると失敗しかねません。kexec で「健全な別カーネル」に主導権を渡すことで、汚染領域に手を触れずに /proc/vmcore 経由で吸い出せます。採取した vmcore は crash ユーティリティで解析し、パニック時のスタック・レジスタ・ロック状態を復元できます。

まとめ

• パニック は回復不能としてカーネル全体を停止し、Oops / BUG は該当プロセスを kill して延命を試みるが、内部状態が汚染され得るため panic_on_oops で早期昇格させるのが安全。
• ハングは自己申告できないため 外部からの周期監視（ウォッチドッグ） が必須で、止まり方の深さに応じて検出経路を変える。
• ソフトロックアップ はタイマ割り込み経由で「スケジューラに戻らない CPU」を、ハードロックアップ はマスク不能な NMI 経由で「割り込みすら通らない CPU」を、hung task watchdog は全タスク走査で「D 状態のまま進まない個別タスク」を検出する。
• panic 後は panic_timeout で再起動を、kdump（kexec で別カーネルへ切り替え /proc/vmcore を保存） でダンプ採取を制御し、原因保全と自動復旧のバランスを設計する。関連する障害設計は OOM Killerとメモリ過剰コミットの設計 も参照してください。