Kdump & Crash
标签: 杂谈 | 分类: Linux系统 |
Kdump & Crash 学习笔记 连接:
http://blog.chinaunix.net/space.php?uid=24563208&do=blog&frmd=2274&view=me
现在,可以敲下回车了!短暂的花屏、神秘字符之后,会出现很多信息了!具体的我就不贴出来了,也没办法贴,因为那个时候已经没有办法复制了!
http://blog.chinaunix.net/space.php?uid=24563208&do=blog&frmd=2274&view=me
Kdump & Crash 学习笔记(五) (2010-09-18 10:44)
分类: Kdump
五:System-config-kdump
其实Kdump也有图形化的配置的,之所以放到后面说是因为我认为学习Linux还是不要通过GUI的前端来作各种设置,因为过分依赖这些东西对学习没有什么好处。
System-config-kdump是个用Python写的前端,安装方法如下:
对于其他发行版,应该也有相应的GUI前端,这里就不再多说了。安装好后,可以在系统->管理->Kdump找到:[root@Derek-Laptop derek]# yum install -y system-config-kdump
对比我的/boot/grub/grub.conf可以看到,我保留了256M的内错给Crash Kernel。你可以通过System-config-kdump来调整Kdump Memory,也可以通过修改/boot/grub/grub.conf,个人推荐后者。这里有一个Total System emory,大家可以通过看看源代码来找出System-config-kdump是怎么获得这个数字的,因为本人遇到过一个Bug,是System-config-kdump因为检测不出内存,而直接退出的情况。给大家一点提示,System-config-kdump如果需要获得当前内存信息,那么,有二个文件可能被使用:/proc/iomem 和/proc/meminfo 。
除了可以调整Kdump Memory之外,System-config-kdump还能够配置Dump Target:
这里所显示的和以前说的没有区别,非常容易看懂这个。另外System-config-kdump还能修改FIlter:
左边的Filtering Level就不再多说了,重点说说右边的Output file format。可能大家不知道为什么这里的选项不可选,是因为这是由/sbin/makedumpfile决定的,当输出为ELF格式的时候,也就是添加 -E参数,是不能与-c联合使用的,ELF不支持任何压缩。具体的请/sbin/makedumpfile --help。
剩下的Expert setting没什么好说的,有时间在这里做Expert倒不如直接修改文件来的更快:
这些就是System-config-kdump的配置了,非常简单。但是如果不理解他读取了哪些文件,是没有办法理解Kdump的。所以还是推荐大家使用配置文件,而不是GUI前端。
Kdump & Crash 学习笔记(六) (2010-09-18 18:56)
分类: Kdump
六:Kdump一些琐碎的东西
Kdump讲的差不多了,还有一些琐碎的东西要说。首先就是blacklist这个Feature:
查看/sbin/mkdumprd这个文件,可以看到很多函数。先说明一下,/sbin/mkdumprd是个shell的脚本,如果对脚本不熟悉的话,可能难以理解。Shell在Linux下是非常非常强大的,这是后话了,先看看这个函数:
这个函数就是实现blacklist这个Feature的。这个Feature的大致目的就是,如果你不希望一些内核模块在Crash Kernel中被加载的话,可以在/etc/kdump.conf添加这样一行:do_blacklist(){local modName=$1if echo "$modName" | grep -q "\/" ; thenlocal dirName="/lib/modules/$kernel/$modName"find $dirName -xtype f -exec basename {} \; | sed "s/^\(.*\).ko/blacklist \1/g" >> $MNTIMAGE/etc/blacklist-kdump.confelseecho "blacklist $modName" >> $MNTIMAGE/etc/blacklist-kdump.conffi}
blacklist iwl3945
这里用的是iwl3945,我的是Intel Corporation PRO/Wireless 3945ABG的无线网卡,我不想在Crash Kernel中加载iwl3945的内核模块,就可以像上面那样写在/etc/kdump.conf中,blacklist这个配置的例子在Yum安装的时候,是没有写在默认的配置文件之中的,而且在System-config-kdump之中更别提这些Feature了。所以建议大家使用配置文件来进行Linux的配置。
举iwl3945这个例子是源于一个Bug,遇到过一个Bug,是因为iwl3945这个模块导致Crash Kernel无法启动,禁用这个模块就可以正常启动了。当然了,这个Bug已经被Upstream修复了!
另外的一个琐碎的东西是default选项。这个选项其实并不只有shell reboot halt选项的,通过这段代码就能看出来:
default)DEFAULT_ACTION=$config_valcase $DEFAULT_ACTION inreboot|shell)FINAL_ACTION="reboot -f";;halt)FINAL_ACTION="halt -f";;poweroff)FINAL_ACTION="poweroff -f";;esac;;
其实还有poweroff这个选项的。当然了,你还能做的更多,比如说手动添加一个启动到Single的模式!看吧,这就是看源码的好处,总能有很多新的发现^_^
Kdump的学习差不多就这些了,当然还有更多更多的深层次的东西,比如说kexec的机制、mkdumprd脚本等等。还有很长的路要走......
Kdump & Crash 学习笔记(七) (2010-09-19 21:20)
分类: Kdump
七:Crash的准备工作
Crash这个工具真是非常的强大,具体就不说了,详细的介绍、安装请看Kdump & Crash 学习笔记(一)。
如果大家仔细的看了前面的几篇文章,那现在就是介绍如何实验的时候了!首先需要触发一个Crash,有以下几种方法可以选择:
1) AltSysRq C
Kdump能够通过键盘的组合键来触发:Alt+SysRq+C。如果使用的是HMC,那还可以通过Ctrl+O+C来触发
2) NMI_WATCHDOG
如果是硬件导致的Hang,很可能造成AltSysRq C这种方法失效,因为你的键盘可能都没有反应了。这个时候,NMI Watchdog的特性就能够派上用场了。注意的是,这个特性必须在内核之中启用
3) Kernel OOPs
这也可以产生一个Dump,如果你希望每次Kernel OOPs的时候,都产生一个Dump的话,那么可以:
echo 1 > /proc/sys/kernel/panic_on_oops
4) NMI button
如果系统已经是处在Hang的状态的话,那么可以使用NMI按钮来触发Kdump。开启这个选项可以:
需要注意的是,启用这个特性的话,是不能够同时启用NMI_WATCHDOG的!否则系统会Panic!!!echo 1 > /proc/sys/kernel/unknown_nmi_panic
5) Force-crash
最后,也是实验需要用的方法。强制触发一个Crash:
需要注意的是,一旦你这么做了,你的系统就死了!所以,如果你已经保存好你的数据了,并且不担心原地复活过程中SELinux可能的Relabel的话,同时非常冒险、学习的精神!那你可以敲下回车了![root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger
6) PPC还有一些别的方法,就不细说了,还是以ix86和x86_64为主,如果有需要,请Mail、留言、谷老师!
先贴一下我的配置文件,首先是/boot/grub/grub.conf:
然后是/etc/kdump.conf:[root@Derek-Laptop derek]# cat /boot/grub/grub.confdefault=0timeout=3splashp_w_picpath=(hd0,0)/grub/splash.xpm.gzhiddenmenutitle Fedora (2.6.34.6-54.fc13.i686.PAE)root (hd0,0)kernel /vmlinuz-2.6.34.6-54.fc13.i686.PAE ro root=/dev/mapper/vg_dereklaptop-lv_root rd_LVM_LV=vg_dereklaptop/lv_root rd_LVM_LV=vg_dereklaptop/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us rhgb quiet rdblacklist=nouveau crashkernel=256Minitrd /initramfs-2.6.34.6-54.fc13.i686.PAE.img
手动强制触发Kdump之前,确认一下Kdump服务:[root@Derek-Laptop derek]# tail /etc/kdump.conf#kdump_post /var/crash/scripts/kdump-post.sh#extra_bins /usr/bin/lftp#disk_timeout 30#extra_modules gfs2#default shellext4 UUID=2c560b75-fc2b-4346-a669-6403e954498apath /var/kdumpcore_collector makedumpfile -c --message-level 1 -d 31default shell
如果你的不是operational,建议你别回车,否则,你的Fedora就真的死了![root@Derek-Laptop derek]# service kdump statusKdump is operational
现在,可以敲下回车了!短暂的花屏、神秘字符之后,会出现很多信息了!具体的我就不贴出来了,也没办法贴,因为那个时候已经没有办法复制了!
在这个过程之中,眼睛好使的话,能够看到trigger a crash这样的信息的,还能看到Crash Kernel启动的很多信息,比如说加载模块、等待磁盘准备、等待网络设备、挂载分区等等很多信息,跟Primary Kernel启动的时候是一样的!如果顺利的话,很快就能保存好vmcore,重启电脑了!这个时候需要插一句,如果你没有使用-d选项,那么你是多大的 内存就会完整的保存多大的vmcore。根据需要选择自己的filter Level吧!
重启完成之后,就能回到死而复生的Fedora了!如果你跟我一样,2GB的内存,使用-d 31的级别,不是那么老古董的机子,并且没有遇到SELinux的Relabel的话,估计5分钟就能完成了。
现在来看看我的成果吧:
成功保存了vmcore,好好保留这个文件,以后还指望他分析出当初Crash的原因呢![root@Derek-Laptop derek]# ll /var/kdump/127.0.0.1-2010-09-18-00\:07\:09/vmcore-rw------- 1 root root 21494214 9月 18 08:07 /var/kdump/127.0.0.1-2010-09-18-00:07:09/vmcore
Tips:
本来是有一些文档的,但是涉及一些版权的诸多问题,以后有机会拿出来分享!
Kdump & Crash 学习笔记(八) (2010-10-04 15:46)
分类: Kdump
八:Crash初步
最近有点忙,很久都没有写东西了!翻了一下专辑,上次写到了Crash,这篇是讲Crash初步的东西。
首先得有一个vmcore,可以直接Dump,也可以Mail我o(∩∩)o...
这就是我的vmcore了,总共才45M,Level为31。我的内存为2GB,压缩之后的大小非常客观吧!不过还是根据自己的需要来调整Level吧![root@Derek-Laptop derek]# du -sh /var/kdump/127.0.0.1-2010-10-04-16\:14\:09/vmcore45M /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore
使用Crash来分析vmcore有好几种方法,可以help一下:
第一种就是,跑在Live的系统上,例如:
另外一种就是跑在dumpfile之上,例如:$ crash$ crash /usr/tmp/vmlinux$ crash /boot/System.map vmlinux.dbg$ crash -S vmlinux.dbg$ crash vmlinux vmlinux.dbg
这里的-S表示使用/boot/System.map作为mapfile。所有的Usage为:$ crash vmlinux vmcore$ crash /boot/System.map vmlinux.dbg vmcore$ crash -S vmlinux.dbg vmcore$ crash vmlinux vmlinux.dbg vmcore
我们这里采用的是跑在dumpfile之上的,所以需要安装一个包:Usage:crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist] [dumpfile]
需要注意的是,Kdump产生的vmcore需要对应的kernel-debuginfo才能使用Crash分析,所以需要安装对应的debuginfo!!![root@Derek-Laptop derek]# yum install kernel-debuginfo
罗嗦了这么多,也该进入正题了!
Crash使用了对应的vmlinux来分析保存的vmcore,同时也打印出了一些信息^_^[root@Derek-Laptop derek]# crash /var/kdump/127.0.0.1-2010-10-04-16\:14\:09/vmcore /usr/lib/debug/lib/modules/2.6.34.7-56.fc13.i686.PAE/vmlinuxcrash 5.0.7Copyright (C) 2002-2010 Red Hat, Inc.Copyright (C) 2004, 2005, 2006 IBM CorporationCopyright (C) 1999-2006 Hewlett-Packard CoCopyright (C) 2005, 2006 Fujitsu LimitedCopyright (C) 2006, 2007 VA Linux Systems Japan K.K.Copyright (C) 2005 NEC CorporationCopyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.This program is free software, covered by the GNU General Public License,and you are welcome to change it and/or distribute copies of it undercertain conditions. Enter "help copying" to see the conditions.This program has absolutely no warranty. Enter "help warranty" for details.GNU gdb (GDB) 7.0Copyright (C) 2009 Free Software Foundation, Inc.License GPLv3+: GNU GPL version 3 or laterThis is free software: you are free to change and redistribute it.There is NO WARRANTY, to the extent permitted by law. Type "show copying"and "show warranty" for details.This GDB was configured as "i686-pc-linux-gnu"...KERNEL: /usr/lib/debug/lib/modules/2.6.34.7-56.fc13.i686.PAE/vmlinuxDUMPFILE: /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore [PARTIAL DUMP]CPUS: 2DATE: Mon Oct 4 16:13:36 2010UPTIME: 00:32:28LOAD AVERAGE: 0.94, 0.65, 0.41TASKS: 328NODENAME: Derek-LaptopRELEASE: 2.6.34.7-56.fc13.i686.PAEVERSION: #1 SMP Wed Sep 15 03:27:15 UTC 2010MACHINE: i686 (1662 Mhz)MEMORY: 2 GBPANIC: "Oops: 0002 [#1] SMP " (check log for details)PID: 3347COMMAND: "bash"TASK: efcb4c80 [THREAD_INFO: efcca000]CPU: 0STATE: TASK_RUNNING (PANIC)crash>
下面就是一些Debug工作了,比如说bt命令:
crash> btPID: 3347 TASK: efcb4c80 CPU: 0 COMMAND: "bash"#0 [efccbe38] crash_kexec at c046f511#1 [efccbe90] bad_area at c04280b1#2 [efccbea8] do_page_fault at c07a5e61#3 [efccbed4] error_code (via page_fault) at c07a3a65EAX: 00000063 EBX: 00000063 ECX: c0aa4e08 EDX: 00000000 EBP: efccbf14DS: 007b ESI: c09c171c ES: 007b EDI: 00000003 GS: 00e0CS: 0060 EIP: c0637138 ERR: ffffffff EFLAGS: 00210046#4 [efccbf08] sysrq_handle_crash at c0637138#5 [efccbf18] __handle_sysrq at c06374f7#6 [efccbf40] write_sysrq_trigger at c06375af#7 [efccbf50] proc_reg_write at c05117a1#8 [efccbf74] vfs_write at c04da415#9 [efccbf90] sys_write at c04da50f#10 [efccbfb0] ia32_sysenter_target at c0408c98EAX: 00000004 EBX: 00000001 ECX: b7835000 EDX: 00000002DS: 007b ESI: 00000002 ES: 007b EDI: b7835000SS: 007b ESP: bfc9b1bc EBP: bfc9b1f4 GS: 0033CS: 0073 EIP: 00898424 ERR: 00000004 EFLAGS: 00200246
可以看到,内核崩溃的元凶就是bash了!因为我使用了
除此之外,还可以看到当时的程序栈,相当底层的东西了吧^_^[root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger