【悲報】Linuxは”わざと”フリーズする、理由はデータを守るため…カーネルパニックの4つの絶対命令とログ消失の謎
画面が固まり、キーボードの操作を受け付けなくなるLinuxの”フリーズ”。一見すると単なるトラブルに見えるが、あの瞬間に内部では、データを守るという目的のためだけに、あえて停止するという設計が動いている。同じように見える「固まり」でも、内部の崩壊レベルは大きく違う。固まった直後に何が起き、なぜ直前のログが消えるのかを順に追うと、その設計哲学がはっきり見えてくる。
Oops と Panic、ふたつの崩壊は別物
まず前提として、画面が固まり始めた状況には2種類ある。1つはカーネルに致命的ではない例外が発生した「Oops」の状態だ。このときカーネルはまだ動いており、問題のあった処理を切り捨てながら継続できる。画面に例外メッセージが浮かんでいてもしばらく操作できるなら、これは回復の一歩手前の状態だ。
もう1つは「Panic（パニック）」と呼ばれる致命的な死だ。カーネル自身がこれ以上継続できないと判定した瞬間、システムは管理者にすら操作を受け付けない完全停止へ向かう。この差は単なる症状の程度ではなく、「あと1行でもデータを書けるか」に関わる。カーネルが壊れた状態でディスクに書き込みを続けると、ファイルシステムそのものが壊れるからだ。
この区別が現実に現れるのが、システム全体の信頼性の調整だ。カーネルには「Oops が起きたら即パニックにする」という挙動を選べるパラメータがあり、航空機の制御系やミッションクリティカルな環境では、むしろ”中途半端に動く”より確実に止まる設定が好まれる。半分壊れた状態が存続してデータを傷つけるより、即座に停止して備えるほうが安全という判断だ。
沈黙の3フェーズと、運命の4つの絶対命令
パニックに至るまでの固まり方には、体感的な3段階があるとされる。まず入力が効かなくなる段階、次にマウスカーソルすら動かなくなる段階、そして最後は画面更新自体が止まる段階だ。この順序は「どのプロセスがまだ動けているか」の現れであり、カーネルが段階的に沈黙していると解釈する材料になる。
パニックの直前、カーネルは重大な判断を下す。そしてそのとき、もう何もできない人間に代わって、カーネルが自分で4つの絶対命令に従うとされている。1つ目は、これ以上の処理を一切起こさないこと。2つ目は、メモリ上に残っている情報を一切共有せず、可能な限り表示に吐き出すこと。3つ目は、これ以上ディスクに書き込まないこと。4つ目は、自動的な復旧を試みず人間を待つこと。つまり、”より安全な自力では復帰しない”のだ。
なぜパニック直前のログは消えるのか
多くの人がもっとも違和感を持つのは、直前の何が起きたかが分からないことだ。だけでなく、直前のログ画面すらスクロールで戻れない。この”ログの消失”はバグではなく、設計上の帰結というべき現象だ。パニックに至ったときには、書き込み系のキャッシュが信頼できない状態に陥っている可能性が高い。ここで「ログをディスクにまとめて書き出してから停止する」という処理を行うと、その書き込み自体が起因になってファイルシステムを壊しかねない。だから停止の前にあえてディスクには書かず、画面とメモリにだけ残す、という選択がされている。
もう1つ直観を裏切る現象が、Taint（汚染）と呼ばれる仕組みだ。カーネルは、独自のモジュールを組み込んだり、特殊な条件で動いた経歴を”刻印”として内部のフラグに記録する。この刻印が立った状態で障害を報告すると、開発者側での正式な支援が限定されることがある。つまりカーネルは、今日の壊れ方だけでなく、過去の運用の履歴まで覚えているのだ。
自分が何を壊したかを後世に届ける「Magic SysRq」
完全なパニックに至る前に、最後の切り札が1つ残されている。Magic SysRq と呼ばれる仕組みだ。キーボードの SysRq キーとの組み合わせ、あるいは proc 系の特殊ファイルへの書き込みを通じて、カーネルに診断用の命令を直接送れる。各処理を順番に落としたり、メモリの内容だけを表示させて止めたり、ファイルシステムに書き込まず安全に同期させて再起動させたりという操作が可能で、パニック直後でもはかどる状態を固定し、後日解析に持ち越せる熱量に変換してくれる。
通称 REISUB と呼ばれる手順は、この組み合わせの代表的な運用例として知られる。各段階で sync による同期とファイルシステムの安全な切り離しを実行した上で最後に再起動に移る流れで、データへの影響を最小限に抑えながら固まったマシンに秩序を取り戻させる手順だ。sysrq の意図は、”ログが消える前に保護しながら安全に再起動する”道筋を、管理者の手が届く形で残しておくことにある。
まとめ：フリーズは設計の帰結であり、読み方を変えれば得られる
まとめると、Linuxカーネルの”フリーズ”は、その瞬間より破壊されるリスクのあるデータを守るという優先順位の元で、合意された段階的な停止だ。Oops と Panic の違いを知り、中途半端に動かし続けるのではなく、Taint や Magic SysRq、crash dump といった後段の仕組みを備えることこそが、管理者がやるべき細やかな心得だ。パニックの直前にログが読めない一瞬があるのも、それ自体がデータを守る結果である。フリーズのたびに”勝手に止まった”と嘆くのではなく、その死に様が何を語っているのかを丁寧に読みかえるきっかけとして捉えたい。