Loading article…
カーネルパニック（略称KP [ 1 ]）は、オペレーティングシステムのカーネルが、内部で致命的なエラーを検出した際に講じる安全対策です。このエラーでは、カーネルが安全に回復できない場合や、システムの実行を継続すると重大なデータ損失のリスクが高くなります。この用語は主にUnixおよびUnixライクなシステムに特有のものです。Microsoft Windowsオペレーティングシステムにおける同等のエラーはストップエラーであり、しばしば「ブルースクリーン・オブ・デス（BSOD）」と呼ばれます。
AT&T由来およびBSD Unix ソースコードでは、パニックを処理するカーネルルーチンとして知られており、一般的にはコンソールにエラー メッセージを出力し、事後デバッグのためにカーネル メモリのイメージをディスクにダンプし、その後、システムが手動で再起動されるのを待つか、自動再起動を開始するように設計されています。[ 2 ]提供される情報は非常に技術的な性質のものであり、システム管理者またはソフトウェア開発者が問題を診断するのに役立つことを目的としています。カーネル パニックは、カーネル空間の外で発生したエラーによっても引き起こされる可能性があります。たとえば、多くの Unix オペレーティングシステムでは、ユーザー空間で実行されるinitプロセスが終了するとパニックが発生します。[ 3 ] [ 4 ]panic()
Unixカーネルは、障害検出メカニズムとしてアサーションを使用して、内部の一貫性と実行時の正しさを維持します。基本的な前提は、ハードウェアとソフトウェアが正しく動作するはずであり、アサーションの失敗はパニック、つまりすべてのシステムアクティビティの自発的な停止につながります。[ 5 ]カーネルパニックはUnixの初期バージョンで導入され、Unixとその前身であるMulticsの設計思想の大きな違いを示しました。Multics開発者のTom van Vleckは、Unix開発者のDennis Ritchieとのこの変更に関する議論を回想しています。
私がデニスに、Multicsで書いているコードの半分以上がエラー回復コードだと指摘したところ、彼は「そういうのは全部省いたんだ。エラーが出たら、panicというルーチンがあって、それが呼び出されるとマシンがクラッシュして、廊下に向かって『おい、再起動しろ！』って叫ぶんだ」と言った。 [ 6 ]
元のpanic()機能は、第5版UNIXからVAXベースのUNIX 32Vまで基本的に変更されておらず、エラーメッセージのみを出力し、その他の情報は出力せず、システムを無限のアイドルループに陥らせていました。Unixのコードベースが拡張されるにつれて、このpanic()機能も拡張され、さまざまな形式のデバッグ情報をコンソールに出力できるようになりました。
ハードウェア障害やオペレーティングシステムのソフトウェアバグの結果としてパニックが発生することがあります。多くの場合、オペレーティングシステムはエラーが発生した後も動作を継続できます。システムが不安定な状態にある場合、セキュリティ侵害やデータ破損のリスクを避けるため、オペレーティングシステムはそれ以上の損傷を防ぐために停止し、エラーの診断を容易にし、自動的に再起動する場合があります。[ 7 ]ソースコード からカーネルバイナリイメージを再コンパイルした後、カーネルが正しく構成、コンパイル、またはインストールされていない場合、結果として生成されたカーネルの起動中にカーネルパニックが発生するのはよくある問題です。 [ 8 ] OSとの非互換性やデバイスドライバの欠落により、アドオンハードウェアや誤動作しているRAMも、起動中に致命的なカーネルエラーの原因となる可能性があります。[ 9 ]ルートファイルシステムが見つからない場合、カーネルは に入ることもあります。[ 10 ]カーネルのユーザースペース初期化の最終段階では、通常、 initの起動に失敗するとパニックが発生します。初期化プロセスが終了するとシステムが使用できなくなるため、パニックが発生する可能性もあります。[ 11 ]panic()
以下は、Linuxカーネルの最終初期化の実装ですkernel_init()。[ 12 ]
static int __ref kernel_init ( void * unused ) {.../* * いずれかが成功するまで、これらをそれぞれ試行します。 * * 本当に壊れたマシンを復旧しようとして いる場合は、init の代わりに Bourne シェルを使用できます。 */ if ( execute_command ) { if ( ! run_init_process ( execute_command )) return 0 ; pr_err ( "%s の実行に失敗しました。デフォルト値を試しています... \n " , execute_command ); } if ( ! run_init_process ( "/sbin/init" ) || ! run_init_process ( "/etc/init" ) || ! run_init_process ( "/bin/init" ) || ! run_init_process ( "/bin/sh" )) return 0 ;panic ( "initが見つかりません。カーネルにinit=オプションを渡してみてください。 " "詳細はLinux Documentation/init.txtを参照してください。" ); }
Linuxカーネルはpanic()最初から基本的な機能を実装しており、バージョン0.01の元の実装は単純に次のとおりでした。 [ 13 ]
volatile void panic ( const char * s ) { printk ( "カーネルパニック: %s \n\r " , s ); for (;;); }しかしその後、カーネル自体が進化するにつれて、パニック時の対応手順はますます洗練されていった。
Linux 6.10以降、drm_panicと呼ばれる新機能がマージされ、DRMドライバがBSODスタイルのパニック画面を描画して、パニックが発生したことをユーザーに通知できるようになりました。これにより、パニックが発生したときにディスプレイサーバが実行されていた場合でも、パニック画面を表示できます。[ 14 ]
Linux 6.12以降、drm_panicが拡張され、スタックトレースをQRコードとしてエンコードできるようになりました。[ 15 ]
現在、3つの選択肢は、ユーザー（デフォルト）、kmesg（旧式）、およびQRコードです。[ 16 ]
Linuxでは、他のUnix 系システムと同様にカーネル パニックが発生します。ただし、深刻ではあるものの致命的ではないエラーは、カーネル oopsと呼ばれる別の種類のエラー状態を引き起こす可能性があります。[ 17 ]この場合、カーネルは通常、問題のあるプロセスを終了した後も実行を継続します。oops は一部のサブシステムやリソースが使用できなくなる原因となる可能性があるため、後に完全なカーネル パニックにつながる可能性があります。
Linuxでは、カーネルパニックが発生すると、キーボードのLEDが点滅して、重大な状態であることを視覚的に示します。[ 18 ]
Mac OS X 10.2 から 10.7 でカーネルパニックが発生すると、コンピュータは多言語メッセージを表示し、システムを再起動する必要があることをユーザーに通知します。[ 19 ] 10.2 より前は、より伝統的な Unix スタイルのパニックメッセージが表示されていました。10.8 以降では、コンピュータは自動的に再起動し、その後はスキップ可能な警告としてのみメッセージが表示されます。メッセージの形式はバージョンによって異なります。[ 20 ]
macOS 10.8 では、最初のカーネルパニックから 3 分以内に 5 回の新たなカーネルパニックが発生すると、Mac は30 秒間禁止マークを表示してからシャットダウンします。これは「繰り返し発生するカーネルパニック」として知られています。[ 21 ]
バージョン10.2以降では、テキストはスタンバイシンボルに重ねて表示され、全画面表示にはなりません。デバッグ情報はNVRAMに保存され、再起動時にログファイルに書き込まれます。バージョン10.7では、カーネルパニック後に自動的に再起動する機能があります。バージョン10.2以降では、スタンバイシンボルに加えて、エラーの詳細を示す白いテキストが表示される場合があります。
