3、内核恐慌：Kernel Panic 场景下的日志抓取与 vmcore 配置

Kernel Panic，说白了就是 Linux 内核遇到了它无法处理的致命错误。这时候系统会直接「罢工」，屏幕上刷出一堆调用栈信息，然后要么挂死，要么自动重启。

我遇到过不少运维新手，一看到 Panic 就慌了，赶紧重启机器。结果呢？现场被破坏了，想查根因都无从下手。其实，Panic 本身并不可怕，可怕的是你没留下证据。

这一章，我们就来聊聊：当内核恐慌发生时，怎么把现场「拍下来」。

3.1 理解 Kernel Panic 的触发机制

先搞清楚一件事：Panic 不是随机发生的。它通常由以下几种原因触发：

• 硬件故障：比如内存 ECC 报错、CPU 缓存一致性错误、PCIe 链路异常。
• 内核 BUG：驱动模块有缺陷、文件系统代码有逻辑漏洞、内存管理模块踩了空指针。
• 关键进程崩溃：init 进程或内核线程意外退出，内核认为系统无法继续运行。
• 资源耗尽：极端情况下，内存或进程表被耗尽，内核无法分配关键资源。

内核在 Panic 时，会调用 panic() 函数。这个函数会做几件事：

1. 打印当前 CPU 的寄存器状态和调用栈。
2. 打印所有 CPU 的 backtrace（如果启用了多核支持）。
3. 尝试刷新日志缓冲区到控制台。
4. 根据 panic_timeout 参数决定是否自动重启。

3.2 日志抓取：抢救 dmesg 的最后机会

如果你的系统 Panic 后没有自动重启，或者你通过 IPMI/iLO 等带外管理卡还能看到控制台输出，那就有机会手动抓取日志。

我个人习惯在 Panic 发生后，第一时间做两件事：

• 拍照：用手机拍下屏幕上的调用栈。虽然原始，但最可靠。
• 串口记录：如果配置了串口控制台，终端模拟器里会保留完整的 Panic 输出。

但说实话，手动抓取太被动了。更专业的做法是——让系统在 Panic 时自动把内存转储下来。这就是 vmcore。

3.3 vmcore 是什么？为什么需要它？

vmcore 是内核 Panic 时，将整个内存内容（或部分内存）导出到磁盘的一个文件。你可以把它理解成「内核的尸检报告」。

有了 vmcore，你可以用 crash 工具或 gdb 来分析：

• Panic 发生时，CPU 正在执行哪条指令？
• 各个进程的堆栈是什么状态？
• 内存中哪些数据结构被破坏了？
• 是哪个内核模块导致的崩溃？

我在项目中遇到过好几次，光看 dmesg 根本看不出问题，但一分析 vmcore，立刻定位到是某个第三方驱动在特定条件下触发了空指针解引用。

3.4 配置 kdump：让系统自动生成 vmcore

kdump 是 Linux 上最常用的 vmcore 捕获机制。它的原理很简单：

1. 系统正常运行时，保留一小部分内存给一个「捕获内核」（capture kernel）。
2. 当主内核 Panic 时，自动切换到捕获内核。
3. 捕获内核启动后，将主内核的内存内容保存到磁盘。

下面是我常用的配置步骤：

3.4.1 安装 kdump 工具

# RHEL/CentOS
yum install kexec-tools crash

# Ubuntu/Debian
apt install kdump-tools crash

3.4.2 预留内存

在 GRUB 内核启动参数中，添加 crashkernel=auto 或手动指定大小：

# 编辑 /etc/default/grub
GRUB_CMDLINE_LINUX="... crashkernel=256M"

# 更新 GRUB 配置
grub2-mkconfig -o /boot/grub2/grub.cfg   # RHEL/CentOS
update-grub                               # Ubuntu/Debian

3.4.3 配置 kdump 服务

# 编辑 /etc/kdump.conf
# 指定 vmcore 保存路径
path /var/crash

# 指定核心收集器（压缩格式）
core_collector makedumpfile -c -d 31

# 可选：指定转储级别（0-31，31 表示全部转储）
# -d 31 表示排除所有可排除的页，减小文件体积

3.4.4 启动并测试

# 启动 kdump 服务
systemctl enable kdump
systemctl start kdump

# 手动触发 Panic 测试（仅限测试环境！）
echo c > /proc/sysrq-trigger

执行 echo c > /proc/sysrq-trigger 后，系统会立即 Panic。重启后，检查 /var/crash 目录下是否生成了 vmcore 文件。

3.5 核心流程：从 Panic 到 vmcore 的完整链路

下面这张图，展示了 kdump 的工作流程：

3.6 避坑指南：我曾经踩过的坑

配置 kdump 看起来简单，但实际落地时有不少细节。我把自己踩过的坑列出来，你遇到了可以少走弯路：

问题场景	原因	解决方案
Panic 后没有生成 vmcore	捕获内核没有预留成功	检查 /proc/cmdline 是否包含 crashkernel 参数
vmcore 文件大小为 0	磁盘空间不足或路径权限错误	确保 /var/crash 有足够空间，且 kdump 用户有写权限
捕获内核启动失败	预留内存太小或内核版本不匹配	增大 crashkernel 值，或更新 kexec-tools 版本
vmcore 无法被 crash 工具解析	缺少对应的 debuginfo 包	安装 kernel-debuginfo 包，版本必须与运行内核一致

3.7 验证配置是否生效

配置完成后，别急着收工。我建议做一次完整的验证：

1. 检查 kdump 服务状态：systemctl status kdump
2. 检查预留内存：cat /proc/iomem | grep Crash
3. 在测试环境触发 Panic，确认 vmcore 生成成功
4. 用 crash 工具打开 vmcore，确认可读

只有验证通过，你才能放心地把机器交还给业务方。否则，真出了事，你连个「尸检报告」都拿不到。