デバッグのためのトラブルシューティングカーネルパニック

私はAWS 12.2でUbuntu 12.04を実行しており、多数のホストが問題になっています。カーネルダンプを有効にしようとしていますが、カーネルパニックをシミュレートすると、ファイルシステムのどこにも.crashファイルが書き込まれません。

私はここの指示に従いました：https : //wiki.ubuntu.com/Kernel/CrashdumpRecipe

そして、物事は正しく設定されているようです：

# cat /proc/cmdline 
root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M

# dmesg |grep crash
[    0.000000] Command line: root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M
[    0.000000] Reserving 64MB of memory at 832MB for crashkernel (System RAM: 1708MB)
[    0.000000] Kernel command line: root=LABEL=cloudimg-rootfs ro console=hvc0  crashkernel=384M-2G:64M,2G-:128M

# cat /sys/kernel/kexec_crash_loaded
1

しかし、実行すると：

# echo c | sudo tee /proc/sysrq-trigger

システムは期待どおりに再起動しますが、いかなる種類の「クラッシュ」ファイルも生成されません。何が悪いのでしょうか？

kdump initscriptが有効になっていることを確認してください。kexec_crashパッケージは、通常の起動ルーチンをバイパスするためにinitscriptに依存しています。の現在の呼び出しがinitクラッシュによって呼び出されたものであるかどうかを判断し、それを使用して、実際の再起動を実行する前に以前の実行状態をダンプする必要があるかどうかを判断します。

とはいえ、テストシステムが64Mbに収まるほど小さくない場合、他のすべてのクラッシュによってメモリの総量が減少していることに気付かなければ、これはおそらく起こっていることではありません。

あなたが探す必要がある主なことは、2番目initが発砲しているかどうかです。システムをクラッシュさせた直後に、コンソールにinitscript起動シーケンスが表示され、その後に再起動が行われるはずです。

• これが発生しない場合、クラッシュカーネルはまったく起動していません。
• これが発生していて、プロンプトが表示される場合は、initscriptが機能していません。（有効になっていないか、クラッシュ後の状態を検出していません）
• これが発生している場合、2回目のinit起動、システムの再起動、再起動initが行われますが、これにもかかわらず、まだファイルがないため、kdump initscriptが再起動を発行する直前に何が起こっているのかをトラブルシューティングする必要があります。皮肉なことに、より良い方法の1つは、initscriptを無効にしてコマンドを手動で実行することです。（注意：これを試す前に、サービスがクラッシュカーネルのメモリに収まることを確認してください！）