最近有一些老的dell机器总是莫名其妙的系统就没有反应了，查案日志系统却发现什么都没有记录，记录的只是启动后的日志，通过监控系统发现在系统在没有反应前cpu、内存、负载、流量都很正常，就是突然没有响应了，排查起问题来很难搞，偶然发现了kdump这个工具，这是一个可信赖的内核崩溃转储工具。下面简单介绍一下该工具：

kexec是一个快速启动机制，允许通过已经运行的内核的上下文启动一个Linux内核，不需要经过BIOS。BIOS可能会消耗很多时间，特别是带有众多数量的外设的大型服务器。这种办法可以为经常启动机器的开发者节省很多时间。Kexec是实现kdump机制的关键，它包括2个组成部分：一是内核空间的系统调用kexec_load，负责在生产内核(production kernel 或 first kernel)启动时将捕获内核(capture kernel或sencond kernel)加载到指定地址。二是用户空间的工具kexec-tools，他将捕获内核的地址传递给生产内核，从而在系统崩溃的时候能够找到捕获内核的地址并运行。没有kexec就没有kdump。先有kexec实现了在一个内核中可以启动另一个内核，才让kdump有了用武之地。

kdump是一种先进的基于kexec的内核崩溃转储机制。当系统崩溃时，kdump使用kexec 启动到第二个内核。第二个内核通常叫做捕获内核，以很小内存启动以捕获转储镜像。第一个内核保留了内存的一部分给第二内核启动用。由于kdump利用kexec启动捕获内核，绕过了 BIOS，所以第一个内核的内存得以保留。这是内核崩溃转储的本质。kdump需要两个不同目的的内核，生产内核和捕获内核。生产内核是捕获内核服务的对像。捕获内核会在生产内核崩溃时启动起来，与相应的ramdisk一起组建一个微环境，用以对生产内核下的内存进行收集和转存。注意，在启动时，kdump保留了一定数量的重要的内存，为了计算系统需要的真正最小内存，加上kdump使用的内存数量，以决定真正的最小内存的需求。

kexec和kdump的设计区别：

的设计是用新内核去覆盖原内核位置；而KDUMP是预留一块内存来加载第二个内核(和相关数据)，Crash后第二个内核在原位置运行(不然就达不到相关目的了)，收集第一个内核的相关内存信息。

下面开始试验kdump特性：

操作系统：ubuntu 12.10(3.5.0-17-generic)

安装kdump工具

apt-get install kexec-tools crash   发现安装过程中修改了grub，在引导内核配置上(/boot/grub/grub.cfg)多了如下参数

crashker nel=384M-2G:64M,2G-:128M   crashkernel用来指定保留内存的大小，我们可以知道crashkernel帮我们设定的保留区域的大小是：如果内存小于384M，不保留内存；如果内存大于等于384M但小于2G，保留64M；如果内存大于2G，保留128M。

修改kdump配置文件(/etc/default/kdump-tools)

USE_KDUMP=1 下载dbgsym文件，改文件是用来吊事内核信息的文件

wagt 'http://ddebs.ubuntu.com/pool/main/l/linux/linux-image-3.5.0-17-generic-dbgsym_3.5.0-17.28_amd64.ddeb'

dpkg -i linux-image-3.5.0-17-generic-dbgsym_3.5.0-17.28_amd64.ddeb   重启机器使配置生效。

启动kdump-tools

/etc/init.d/kdump-tools start

Starting kdump-tools: setup_linux_vesafb: 1280x1024x32 @ d9800000 +500000

* loaded kdump kernel

kdump-tools配置(kdump-config show)：

USE_KDUMP: 1

KDUMP_SYSCTL: kernel.panic_on_oops=1

KDUMP_COREDIR: /var/crash

crashkernel addr: 0x2e000000

current state: ready to kdump

kernel link:

/usr/lib/debug/boot/vmlinux-3.5.0-17-generic

kexec command:

/sbin/kexec -p --command-line="BOOT_IMAGE=/boot/vmlinuz-3.5.0-17-generic root=UUID=9386113e-a6db-4a1c-9565-8c8c1de4a55a ro irqpoll maxcpus=1 nousb" --initrd=/boot/initrd.img-3.5.0-17-generic /boot/vmlinuz-3.5.0-17-generic

可以通过sysrq强制系统崩溃。

echo ‘c’ > /proc/sysrq-trigger

这造成内核崩溃，如配置有效，系统将重启进入kdump内核，当系统进程进入到启动 kdump服务的点时，(dump.时间戳文件)将会拷贝到你在kdump配置文件中设置的位置。ubuntu的缺省目录是:/var/crash/时间戳文件夹。然后系统重启进入到正常的内核。一旦回复到正常的内核，就可以在上述的目录下发现dump文件，即内存转储文件。可以使用之前安装的crash工具来进行分析。

生成dump文件后/var/crash的目录结构：

├── 201305061817

│   ├── config_link -> /boot/config-3.5.0-17-generic

│   ├── dump.201305061817

│   ├── kernel_link -> /usr/lib/debug/boot/vmlinux-3.5.0-17-generic

│   └── system.map_link -> /boot/System.map-3.5.0-17-generic

├── config_link -> /boot/config-3.5.0-17-generic

├── kernel_link -> /usr/lib/debug/boot/vmlinux-3.5.0-17-generic

├── kexec_cmd

└── system.map_link -> /boot/System.map-3.5.0-17-generic   ump.201305061817就是生成的dump文件，后面的一串数字诶当时的时间戳。

接下来用crash进行分析

crash /usr/lib/debug/boot/vmlinux-3.5.0-17-generic dump.201305061817 出现如下错误提示：

crash: cannot resolve: "xtime"，此时crash的版本为5.1.6，版本太低，调试不了3.5的内核，需要升级crash，可以手动安装crash。最新版为6.1，可以调试到3.6的内核。参照：

http://people.redhat.com/anderson/

参考：

http://www.ibm.com/developerworks/cn/linux/l-cn-kdump1/index.html

http://www.ibm.com/developerworks/cn/linux/l-cn-dumpanalyse/?

http://manpages.ubuntu.com/manpages/natty/man5/kdump-tools.5.html

http://hi.baidu.com/gpstrive/item/68929aa083f69416a9cfb773

http://bbs.chinaunix.net/thread-1919319-1-1.html????