某台机器在执行 sync;reboot 后出现了 kernel panic，给 rhn 提 issue，指导我们使用 kdump 把 panic 时的内存给 dump 下来，很早就听说 kdump，趁此机会学习下使用方法。
kdump 需要两个不同目的的内核，生产内核和捕获内核。生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启动起来，与相应的 ramdisk 一起组建一个微环境，用以对生产内核下的内存进行收集和转存。
kdump 使用 kexec 机制来 dump kernel panic 时候的内存信息 从 rhel5 开始，kexec-tools 已被默认安装在发行版。当出现 kernel panic 时，kdump 使用 kexec 启动到第二个内核，也叫 capture kernel 或者 second kernel，出现 panic 的那个叫做 production kernel 或 first kernel，在 first kernel 崩溃时，second kernel 会启动起来，该 first kernel 保留了内存的一部分给 second kernel 启动使用，这个 second kernel 就能够收集和转存 first kernel 的内存信息以提供诊断。
/proc/vmcore 可以选择 dump 到本地的 fs，nfs、ssh，或者是设备。默认(kdump.conf 里面的 path 选项)是直接 dump 到 /var/crash/ 目录下。其他的比较方便的诸如 ssh 直接 RTFM 就好了，kdump.conf 里面的注释写的很清楚。
要使用 kdump，首先要在 /etc/grub.conf 追加上 crashkernel=128M。其实正确的格式是 crashkernel=X@Y，X 是为 kdump 捕获内存保留的内存，Y 是保留部分内存的开始位置。不过正常情况下，可以直接忽略 @X 这部分，对于 Y，正常的 amd64 128M 就可以了。
设置完上面这些之后，重启:
# chkconfig kdump on
# reboot
# service kdump status
Kdump is operational
# service kdump start
查看 /sys/kernel/kexec_crash_loaded 值判断 second kernel 是否加载，1 为已加载否则未加载。
测试一下，正常情况下应该在 /var/crash/ 下面产生一个类似 127.0.0.1-2013-01-24-19:05:36 的目录，里面有一个叫 vmcore 的文件:
# echo c > /proc/sysrq-trigger
# ll /var/crash/127.0.0.1-2013-01-24-19:05:36/
total 147924
-rw——- 1 root root 151467950 Jan 24 19:06 vmcore
正常情况下，产生的 vmcore 会比较大，可以使用 kdump.conf 里面的 core_collector 来进行『裁剪』，包括哪些类型(zero, cache, private, user, free)的 pages 需要保留，这面这个表示
zero pages, cache pages, cache private, user pages, free pages 都不需要 dump 到 vmcore 里面，并且将剩下的数据做压缩:
core_collector makedumpfile -d 31 -c
每次修改完 kdump.conf，需要重启服务:
# service kdump restart
除了使用命令行的方式，RH 还提供一个图形化的叫做 system-config-kdump 工具，可以试试。
对于事后的诊断，可以使用 crash 这个工具，需要安装 kernel-debuginfo 内核调试的工具，详细的使用可以参见这里。
相关文章
转载请注明：爱开源 » kdump 收集 kernel panic 信息