☰

记录内核恐慌以进行调试时出现问题

tag-icon • tag-icon kernel-panic crash
记录内核恐慌以进行调试时出现问题

我在 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

系统按预期重新启动，但不会生成任何类型的“崩溃”文件。我可能做错了什么？

答案1

确保 kdump 初始化脚本已启用。 kexec_crash 包依赖于 initscript 来绕过正常的启动例程。它确定当前的调用是否init是由崩溃调用的调用，并使用它来确定在执行真正的重新启动之前是否需要转储先前的运行状态。

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

您需要检查的主要问题是第二个是否init正在射击。系统崩溃后，您应该立即在控制台上看到 initscript 启动序列之前没有重新启动。

  • 如果没有发生这种情况，则您的崩溃内核根本不会触发。
  • 如果发生这种情况并且您出现提示，则说明您的初始化脚本没有完成其工作。 （未启用或未检测到崩溃后状态）
  • 如果发生这种情况，第二个init将触发，系统将重新启动，init开始再次，尽管如此，您仍然没有文件...您需要在 kdump initscript 重新启动之前对发生的情况进行故障排除。具有讽刺意味的是，更好的方法之一是禁用 initscript 并手动运行命令。 （注意：在尝试此操作之前，请确保您的服务可以放入崩溃内核的内存中！）

相关内容