カーネル障害が発生したときにマシンが「コア」ファイルを生成することを確認するには、マシンの「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 番目のカーネルです。そのカーネルにはドライバーなどが含まれているため、クラッシュダンプを保存できます。ただし、これはあまり一般的な設定ではありません。主に、高可用性を必要とし、クラッシュが調査が必要な非常に深刻な問題であるハイエンド システムで使用されます。
たとえば、ubuntu.com の Kernel Crash Dump の crashkernel オプションを参照してください。 (このページには、Ubuntu 16.04 以降、カーネル クラッシュ ダンプ メカニズムがデフォルトで有効になっていると記載されていることに注意してください。)
システムは実際にダンプをメモリの予約済み部分に保存してから再起動し、カーネルは次の起動時に予約済みメモリをディスクに保存すると私は信じています (新しく起動するカーネルは正常な状態にあり、それを実行できるため)。