カーネルパニック
カーネルパニック (kernel panic; KPとも呼ばれる[1]) とは、コンピュータのオペレーティングシステムのカーネルが内部の致命的なエラーを検出したときに取る安全対策である。このエラーでは、安全に回復できないか、システムを実行し続けることができず、大規模なデータ損失のリスクが大幅に高くなる。この用語は主にUnixおよびUnixライクなシステムに特有のものである。Microsoft Windowsオペレーティングシステムの場合、これに相当する用語は「ストップエラー」であり、Windowsの初期バージョンでは青背景でバグチェック画面が表示され[2]、バグチェックコードが表示される (口語的には「死のブルースクリーン」またはBSoDとして知られている)。Xbox Oneプラットフォームでは緑背景で表示され、Windows 10プレビュービルドでも表示される[3]。
AT&Tに由来するBSD Unixソースコードでは、panic()として知られる、panic()を処理するカーネルルーチンは、一般的にコンソールにエラーメッセージを出力し、事後デバッグのためにカーネルメモリのイメージをディスクにダンプし、その後、システムが手動で再起動されるのを待つか、自動再起動を開始するように設計されている[4]。提供される情報は高度に技術的なものであり、システム管理者やソフトウェア開発者が問題を診断するのを支援することを目的としている。カーネルパニックは、カーネル空間の外部で発生したエラーによって引き起こされることもある。例えば、多くのUnixオペレーティングシステムは、ユーザ空間で実行されるinitプロセスが終了するとパニックになる[5]。
歴史
[編集]Unixカーネルは、障害検出メカニズムとしてアサーションを用いて、内部の一貫性と実行時の正確性を維持する。基本的な前提は、ハードウェアとソフトウェアが正しく動作し、アサーションが失敗するとパニックが発生する、つまりシステムの全ての活動が自発的に停止することである[6]。カーネルパニックはUnixの初期バージョンで導入され、Unixとその前身であるMulticsの設計思想の間に大きな違いを示した。Multicsの開発者のトム・ヴァン・ヴレックは、Unixの開発者のデニス・リッチーとこの変更について議論したことを思い出している。
私はデニスに、私がMulticsで書いていたコードの半分はエラー回復コードだと言った。彼は言った「全てを省略した。エラーが発生した場合、パニックと呼ばれるルーチンがあり、それが呼ばれるとマシンがクラッシュし、『おい、再起動しろ』と廊下で大声で叫ぶ。」[7]。
元々のpanic()関数は、UNIX第5版からVAXベースのUNIX 32Vまで基本的には変更されておらず、エラーメッセージだけを出力してそれ以外の情報を何も表示せず、システムを無限のアイドルループに落とした。
V6 UNIXのpanic()関数のソースコード:[8]
/*
* In case console is off,
* panicstr contains argument to last
* call to panic.
*/
char *panicstr;
/*
* Panic is called on unresolvable
* fatal errors.
* It syncs, prints "panic: mesg" and
* then loops.
*/
panic(s)
char *s;
{
panicstr = s;
update();
printf("panic: %s\n", s);
for(;;)
idle();
}
Unixのコードベースが強化されたので、panic()関数も拡張され、さまざまな形式のデバッグ情報がコンソールにダンプされる。
原因
[編集]オペレーティングシステムのハードウェア障害やソフトウェアバグの結果として、パニックが発生する場合がある。多くの場合、オペレーティングシステムは、エラーが発生した後も動作を継続することができる。ただし、システムは不安定な状態にあり、セキュリティ侵害やデータ破損のリスクを冒すよりも、オペレーティングシステムが停止することで、さらなる損傷を防ぎ、エラーの診断を容易にし、通常は再起動する[9]。
ソースコードからカーネルのバイナリイメージを再コンパイルした後、カーネルが正しく構成、コンパイル、またはインストールされていない場合、結果のカーネルを起動中にカーネルパニックが発生することは一般的な問題である[10]。追加されたハードウェアやRAMの誤動作も、OSとの非互換性やデバイスドライバの欠落により、起動時に致命的なカーネルエラーの原因となる可能性がある[11]。ルートファイルシステムを見つけることができない場合、カーネルはpanic()を実行する可能性もある[12]。カーネルユーザ空間の初期化の最終段階では、通常、initプロセスの生成が失敗するとパニックが発生する。initプロセスが終了すると、システムが使用不能になるため、パニックが発生する可能性もある[13]。
以下は、kernel_init()におけるLinuxカーネルの最終初期化の実装である[14]。
static int __ref kernel_init(void *unused)
{
...
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
if (!run_init_process(execute_command))
return 0;
pr_err("Failed to execute %s. Attempting defaults...\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("No init found. Try passing init= option to kernel. "
"See Linux Documentation/init.txt for guidance.");
}
オペレーティングシステムの詳細
[編集]Linux
[編集]
カーネルパニックは、他のUnixライクなシステムと同様にLinuxでも発生するが、kernel oopsとして知られている別の種類のエラー状態を生成することもある[15]。この場合、カーネルは通常、問題のあるプロセスを終了させた後も実行を継続する。oopsにより、いくつかのサブシステムやリソースが利用できなくなる原因となるため、後で完全なカーネルパニックを引き起こす可能性がある。
Linuxでは、カーネルパニックが発生すると、キーボードのLEDが点滅して危機的な状態を視覚的に示す[16]。
macOS
[編集]Mac OS X 10.2～10.7でカーネルパニックが発生すると、コンピュータは、システムを再起動する必要があることをユーザに通知する多言語メッセージを表示する[17]。10.2以前は、より伝統的なUnixスタイルのパニックメッセージが表示されていたが、10.8以降では、コンピュータは自動的に再起動し、再起動後にメッセージが表示されるようになった。メッセージの形式はバージョンによって異なる[18]。
-
Mac OS X 10.0から–カーネルパニック -
Mac OS X10.2カーネルパニック -
Mac OS X –から10.5カーネルパニック -
Mac OS X10.6および10.7カーネルパニック -
OS X 10.8以降のバージョンでカーネルパニックが発生したため、コンピューターを再起動した後に表示されるメッセージ
関連項目
[編集]脚注
[編集]- ^ “KP - Kernel Panic (Linux) | AcronymFinder”. www.acronymfinder.com. 2016年1月6日閲覧。
- ^ “Bug Checks (Blue Screens)”. Hardware Dev Center - Microsoft. 2020年11月4日閲覧。
- ^ Hoffman. “Did You Know Windows 10 Has a Green Screen of Death?” (英語). How-To Geek. 2020年6月4日閲覧。
- ^ “FreeBSD 11.0 - man page for panic (freebsd section 9) - Unix & Linux Commands”. www.unix.com. 2020年11月16日閲覧。
- ^ “boot failure-init died - Unix Linux Forums - HP-UX”. www.unix.com. 2020年11月16日閲覧。
- ^ Daniel P. Siewiorek; Robert S. Swarz (1998). Reliable computer systems: design and evaluation. A K Peters, Ltd.. p. 622. ISBN 978-1-56881-092-8 May 6, 2011閲覧。
- ^ “Unix and Multics”. www.multicians.org. 2020年11月16日閲覧。
- ^ Source code /usr/sys/ken/prf.c from V6 UNIX
- ^ Steven M. Hancock (November 22, 2002). Tru64 UNIX troubleshooting: diagnosing and correcting system problemsHP Technologies SeriesITPro collection. Digital Press. pp. 119–126. ISBN 978-1-55558-274-6 May 3, 2011閲覧。
- ^ Michael Jang (2006). Linux annoyances for geeks. O'Reilly Media, Inc.. pp. 267–274. ISBN 978-0-596-00801-7 April 29, 2011閲覧。
- ^ David Pogue (December 17, 2009). Switching to the Mac: The Missing Manual, Snow Leopard Edition. O'Reilly Media, Inc.. p. 589. ISBN 978-0-596-80425-1 May 4, 2011閲覧。
- ^ Greg Kroah-Hartman (2007). Linux kernel in a nutshell. O'Reilly Media, Inc.. p. 59. ISBN 978-0-596-10079-7 May 3, 2011閲覧。
- ^ Wolfgang Mauerer (September 26, 2008). Professional Linux Kernel Architecture. John Wiley and Sons. pp. 1238–1239. ISBN 978-0-470-34343-2 May 3, 2011閲覧。
- ^ linux/init/main.c, LXR Cross Referencer
- ^ “Linux Device Drivers, Chapter 4”. 2020年11月16日閲覧。
- ^ James Kirkland; David Carmichael; Christopher L. Tinker; Gregory L. Tinker (May 2006). Linux Troubleshooting for System Administrators and Power Users. Prentice Hall. p. 62. ISBN 9780132797399 2016年2月5日閲覧。
- ^ “OS X: About kernel panics - Apple Support”. support.apple.com. 2023年1月1日時点のオリジナルよりアーカイブ。2020年11月16日閲覧。
- ^ “A New Screen of Death for Mac OS X”. OSXBook.com. 2020年11月16日閲覧。[リンク切れ]