Steamでゲームをしていますが、突然カーネルパニックが発生しました。手動でコンピュータをシャットダウンしてLinux Mint 17.1(Cinnamon)64ビットで再起動した後、ログファイルを確認してみましたが、発生した/var/log/
カーネルパニックに関する参考資料やメッセージは見つかりませんでした。
奇妙なことは、コアをダンプしないか、ログファイルに書き込まない理由です。カーネルパニックが再び発生した場合、コアが常にダンプされるようにするにはどうすればよいですか?カーネルパニックが発生したときに何も記録されない理由はわかりません。 Googleを見てみると、人々が、、などを読んでみると提案しましたが/var/log/dmesg
何/var/log/syslog
もありませ/var/log/kern.log
んでし/var/log/Xorg.log
た。.Xsession-errors
ファイルにもありません。
このようなことが再び発生した場合はいつでも画面の写真を撮ることができますが、カーネルパニックが発生した場合はコアをダンプしてログファイルを生成できることを確認したいと思います。
答え1
カーネルエラーが発生した場合にコンピュータから「コア」ファイルを生成するには、コンピュータの「sysctl」設定を確認する必要があります。
IMOでは、以下を設定する必要があります(最小)/etc/sysctl.conf
。
kernel.core_pattern = /var/crash/core.%t.%p
kernel.panic=10
kernel.unknown_nmi_panic=1
sysctl -p
ファイルが変更された後に実行されます/etc/sysctl.conf
。mkdir /var/crash
まだ存在しない場合は、おそらくそうする必要があります。
キーSysRq(コアダンプのキーの組み合わせはAlt+ SysRq+ C)を使用して手動ダンプを生成して上記の内容をテストできます。
答え2
カーネルパニックが発生すると、カーネルに問題があることを意味します。ログファイルとコアダンプを作成するには、ブロックストレージデバイス(ディスク)とファイルシステム用のドライバが必要です(スペースを割り当てる必要があり、ログファイルのサイズを更新する必要があります)。ファイルに書き込むにはカーネルが提供するサービスが必要で、カーネルは自分が破損した状態にあることを知っているので、もはや安全な状態ではないため、ファイルに書き込んだり何も記録することはできません。状況をさらに悪化させ、ファイルシステムを損傷/損傷する可能性があります。したがって、カーネルにログを書き込むことはできず、パニックが発生した場合にコアダンプをダンプすることもできません。
必要に応じて実行できることは、競合処理カーネルでシステムを構成することです。このカーネルは、プライマリカーネルがクラッシュしたときに制御を転送できるメモリにロードされた2番目のカーネルです。このカーネルにはドライバなどがあり、クラッシュダンプを保存できます。ただし、これは非常に一般的な設定ではなく、主に高可用性を必要とする高度なシステムで使用され、競合は調査する必要がある非常に深刻な問題です。
たとえば、crashkernelオプションを参照してください。カーネルクラッシュダンプubuntu.comから。 (このページはUbuntu 16.04以降、カーネルクラッシュダンプメカニズムがデフォルトで有効になっていることを示しています。)
私は実際にシステムが再起動する前にダンプを予約メモリに保存し、カーネルが次回起動したときに予約メモリをディスクに保存すると信じています(新しく起動したカーネルは正常であり、これを実行できるため)。