服务器内核panic崩溃，kdump配置

服务器突然重启、黑屏或完全无响应，登录后看到的是 system log 里的一行 kernel panic，这时候大多数人的第一反应是重装系统。
其实 Linux 内核自带了一套崩溃转储机制 kdump，它能在内核 panic 的时候把内存现场保存成 vmcore 文件，之后再用 crash 工具慢慢分析。
本文就按照零基础可操作的方式，讲清 kdump 的配置、触发测试和崩溃转储分析全流程。

先判断你的服务器是否需要 kdump

不是所有宕机都适合用 kdump 排查。
如果你的业务是 MySQL、Nginx 这种进程级别的故障，应用本身崩溃会留下 core dump，和内核 panic 无关，不需要配 kdump。
只有当系统出现以下现象时，才需要考虑启用：

• 控制台直接输出 Kernel panic - not syncing，系统完全卡死；
• 服务器自动重启，重启后 dmesg 里找不到正常关机记录；
• 硬件驱动、内核模块或内存故障导致系统无法响应，连 SSH 都断掉。

结论：kdump 只解决内核层面的崩溃现场保留问题，不解决应用层故障。 如果系统只是负载高、进程被杀，优先查应用日志，别急着动内核参数。

安装并配置 kdump 服务

主流发行版都自带 kdump 相关包，但默认可能没启用。
这里以 CentOS/Rocky 系列为例，Ubuntu/Debian 的包名略有不同，但思路一样。

# CentOS/Rocky
yum install kexec-tools crash -y

# Ubuntu/Debian
apt install linux-crashdump crash kexec-tools -y

安装完成后，需要修改内核启动参数，预留一段内存给 kdump 内核。
编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 中加上 crashkernel=256M。
如果服务器内存较大，可以适当调高，例如 crashkernel=512M。

GRUB_CMDLINE_LINUX="... crashkernel=256M"

然后重新生成引导配置并重启系统：

grub2-mkconfig -o /boot/grub2/grub.cfg   # CentOS/Rocky
# Ubuntu 使用 update-grub
reboot

重启后检查 kdump 是否处于可用状态：

systemctl status kdump
kdumpctl status

如果显示 Kdump is operational，说明内核已经预留了崩溃转储所需的内存。

主动触发一次内核 panic 验证配置

生产环境当然不能随便重启，但为了验证 kdump 配置是否生效，建议在测试机或维护窗口内主动触发一次 panic。
常用方式是使用 sysrq 魔术键：

echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger

执行后系统会立刻模拟内核崩溃并触发 kdump。这一步会造成服务器重启，
千万别在业务高峰期试。 重启后检查转储文件，
CentOS/Rocky 默认保存在 /var/crash，
Ubuntu 通常在 /var/lib/systemd/coredump 或 /var/crash。

ls -lh /var/crash/

你会看到类似 127.0.0.1-2025-04-01-10:30:00/vmcore 的目录，里面就是完整的内存转储。
如果目录为空，说明 kdump 没抓到现场，需要回看避坑部分。

使用 crash 工具分析 vmcore

拿到 vmcore 后，用 crash 工具打开它。crash 需要匹配的系统内核符号表，一般发行版的调试符号包会带，没有的话需要安装 kernel-debuginfo。

crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-2025-04-01-10:30:00/vmcore

进入交互界面后，优先执行这几个命令：

• bt：查看崩溃时的内核调用栈，直接定位 panic 发生在哪个函数；
• log：导出内核日志，搜索 panic、Oops、BUG 关键字；
• ps：查看崩溃瞬间所有进程状态，找出哪个进程触发了问题；
• files：查看打开的文件句柄，排查是否和文件系统相关；
• dev -d：查看设备状态，确认驱动是否异常。

crash> bt
crash> log | grep -i panic

一次完整的崩溃分析，至少要看 bt 和 log 两条信息。 如果调用栈里出现硬件驱动函数，优先怀疑驱动或设备；
如果停在内核内存管理模块，则要检查内存条或 swap 配置。

避坑指南与高频问题

crashkernel 参数没生效。
很多新手改完 grub 直接重启，结果 kdumpctl status 仍显示未运行。
这时执行 cat /proc/cmdline，确认输出里有没有 crashkernel=256M。
如果没有，说明 grub 配置没正确更新，或者使用了 UEFI 引导，需要检查 /boot/efi/EFI/centos/grub.cfg。

磁盘空间不足导致转储失败。vmcore 的大小通常接近服务器物理内存，比如 16GB 内存的机器可能产生 10GB 以上的转储文件。
配置 kdump 前，务必确认 /var/crash 所在分区有足够剩余空间，或者把转储路径指向一个独立大分区。

Secure Boot 干扰。
部分 UEFI 机器开了 Secure Boot 后，kdump 内核签名校验失败，抓不到 vmcore。
如果确认是这个原因，可以在 BIOS 中临时关闭 Secure Boot 测试，但不建议为调试一直关着。

误以为 kdump 能解决所有崩溃。
如果服务器直接断电、硬件物理故障或者虚拟机被强制终止，kdump 根本没有机会运行，自然也不会有 vmcore。
它只适合内核仍在 CPU 上执行但逻辑已经崩掉的场景。

如果你在配置过程中发现 kdump 服务始终无法启动，可以先查看服务日志：journalctl -u kdump。
日志里通常会明确提示缺少内核模块、内存不足或路径不可写。
对于自己排查不出来、又急需恢复生产的服务器，先把 kdump 停用，恢复业务优先，再用测试环境慢慢分析。

最后回到流程本身：安装 kexec-tools、设置 crashkernel、开启服务、触发 panic、抓取 vmcore、用 crash 分析 bt 和 log，这套链路就是应对内核 panic 崩溃最实用的做法。
建议你在测试环境完整跑一遍，确认转储文件能正常生成，再部署到生产服务器。
毕竟真等到崩溃发生时才找配置错误，已经来不及了。