故障日志记录内核紧急调试

我在AWS / EC2上运行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初始化脚本。kexec_crash软件包依靠初始化脚本来绕过正常的启动例程。它确定当前的调用是否init是由崩溃调用的，并使用它来确定在执行真正的重新引导之前是否需要转储先前的运行状态。

就是说，如果您的测试系统不够小，无法容纳64Mb，而您又没有注意到其他所有崩溃都会减少您的总内存，则可能不是这种情况。

您需要查找的主要内容是第二个是否init正在射击。在使系统崩溃之后，您应该立即在控制台上看到初始化脚本启动序列，该序列没有重新启动。

• 如果这没有发生，则崩溃内核根本不会触发。
• 如果发生这种情况，并且提示您输入错误，则您的initscript未完成其工作。（它未启用或未检测到崩溃后状态）
• 如果发生这种情况，第二个init触发时，系统会重新启动，init启动再次，尽管这一切，你还没有文件......你需要什么内核转储启动脚本问题，重新启动前右去解决问题。具有讽刺意味的是，更好的方法之一是禁用初始化脚本并手动运行命令。（警告：尝试执行此操作之前，请确保您的服务可以装入崩溃内核的内存中！）