什么是Kdump?
Kdump 是一种的新的crash dump捕获机制,用来捕获kernel crash时候产生的crash dump。Kdump需要配置两个不同目的的kernel,其中一个我们在这里称作standard(production) kernel;另外一个称之为Crash(capture)kernel。
standard(production)kernel,是指我正在使用的kernel,当standard kernel在使用的过程中出现crash的时候, kdump会切换到crash kernel, 简单来说,standard kernel会正运行时发生crash,而crash(capture) Kernel 会被用来捕获production kernel crash时候产生的crash dump。
捕获crash dump是在新的crash(capture) kernel 的上下文中来捕获的,而不是在standard kernel上下文进行。
具体是当standard kernel方式crash的时候,kdump通过kexec(后面介绍)自动启动进入到crash kernel当中。如果启动了kdump服务,standard kernel会预留一部分内存, 这部分内存用来启动crash kernel。
kdump机制主要包括两个组件:kdump和kexec
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的设计区别:
Kexec的设计是用新内核去覆盖原内核位置;而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。