Linux 内核崩溃与 kdump：给服务器装上飞行记录仪
概述 凌晨三点，你被告警吵醒，登录服务器发现屏幕上只有一行 Kernel panic - not syncing: Fatal exception，然后系统就重启了。等你好不容易连上去，崩溃现场什么都没留下——没有日志，没有 core dump，没有调用栈。你只能对着一句 systemd-logind: System is going down 发呆。 这种场景，每个干过几年运维的人都遇到过。内核崩溃本身已经够头疼了，但更头疼的是崩溃后什么都抓不到，问题根本没法定位。 kdump 就是解决这个问题的。它相当于给 Linux 服务器装了一台飞行记录仪——飞机坠毁时，黑匣子能告诉你最后几秒发生了什么；内核崩溃时，kdump 能把崩溃瞬间的完整内存状态保存下来，让你事后用 crash 工具逐帧分析。 这篇文章不讲虚的，从 kdump 的工作原理到生产环境的完整配置流程，再到 crash 工具的实际分析操作，全部覆盖。读完之后，你应该能在自己的服务器上搭一套可靠的崩溃捕获系统。 kdump 是怎么工作的 双内核机制 要理解 kdump，先搞懂一个关键概念：崩溃时主内核已经不可信了。你不能指望一个已经 panic 的内核去把自己的内存好好保存下来——它连正常执行代码都做不到。 kdump 的思路很巧妙：系统启动时，提前预留一块物理内存，在里面加载一个精简的"捕获内核"（capture kernel，也叫第二内核）。主内核正常运行时，这块内存被隔离，谁都不许动。一旦主内核崩溃，kexec 机制会直接把 CPU 控制权交给捕获内核——不走 BIOS，不重启硬件，直接在预留内存里启动。捕获内核接管后，主内核的内存内容还完好无损地躺在那里，捕获内核把它打包成 vmcore 文件，写到磁盘上。 整个过程像这样： ┌──────────────────────────────────────────────┐ │ 物理内存布局 │ │ │ │ ┌────────────────┐ ┌───────────────────┐ │ │ │ 主内核区域 │ │ 预留内存区域 │ │ │ │ (正常运行) │ │ (crashkernel) │ │ │ │ │ │ │ │ │ │ 用户进程 │ │ 捕获内核 + │ │ │ │ 内核模块 │ │ initramfs │ │ │ │ 页缓存....