Kdump & Crash 学习笔记

四：设置Kdump

    上次说过了Kdump配置Dump Target，这次来说说Kdump其他的配置选项：

#path /var/crash

#core_collector makedumpfile -c

#link_delay 60

#kdump_post /var/crash/scripts/kdump-post.sh

#extra_bins /usr/bin/lftp

#disk_timeout 30

#extra_modules gfs2

#default shell

    1) path /var/crash这个在上次已经说过了，就不再赘述了。重点需要讲一下的是core_collector这个选项！core_collector这个选项非常有用，下面就详细说一下core_collector：

    2) core_collector是用来指定内核收集的，例子里采用的是makedumpfile作为收集器。查找一下系统，发现makedumpfile位于这个位置：

[root@Derek-Laptop derek]# whereis makedumpfile

makedumpfile: /sbin/makedumpfile

    makedumpfile有很多选项，简要列了一下：

    -c: Compress dump data by each page.

    -d: Specify the type of unnecessary page for analysis.

Dump  |  zero   cache   cache    user    free

  Level |  page   page    private  data    page

  -------+---------------------------------------

      0  |

      1  |  X

      2  |         X

      4  |         X       X

      8  |                          X

    16  |                                  X

    31  |  X      X       X        X       X

    --message-level: Specify the message types.

Message | progress    common    error     debug     report

   Level   | indicator   message   message   message   message

   ---------+------------------------------------------------------

          0 |

          1 |     X

          2 |                X

          4 |                          X

       * 7 |     X          X         X

          8 |                                    X

        16 |                                              X

        31 |     X          X         X         X         X

    需要注意的是-d选项，这在拥有巨大内存的机器上非常有用。例如SGI的UV，几个TB的内存全部Dump的话，非常低效。这个时候，加上-d 31，也就是Kdump在makedumpfile的时候，过滤掉zero page, cache page, cache private, user data, free page。这会大大加速Dump的速度，生成更小的vmcore。如果不需要全部过滤，那也可以通过指定其他的级别，最大为31，最小为0，也就是不做过滤。

    还有就是--message-level的选项，如果熟悉Kernel的Message Level的话，这个应该不难理解。如果不了解的话，也没有关系，因为这个选项在我使用Kdump的时候，并不常常用到。可能是水平不够^_^

    我在学习的过程中，最常用的就是：

core_collector makedumpfile -c -d 31

    3) link_delay 60这个选项一般与网络Dump相关，因为有些情况下，网络建立有一定的延迟，比如说DNS、IP、Gate等等情况下有延迟。所以设定60秒的延迟，在Kdump内核启动后，会等待60秒，等待网络的建立，再生成vmcore，通过NFS、SCP来传输vmcore。

    4) kdump_post /var/crash/scripts/kdump-post.sh这个可以用来在Dump vmcore完毕后执行一个脚本。用户可以自定义需要执行的动作。

    5) extra_bins /usr/bin/lftp这个可以用来把额外的bin包含到Kdump Kernel中。说到这个就必须要说一下BusyBox了。Busybox把很多UNIX的工具都集成到了一个很小的可执行的文件中，而实际上，在Kdump Kernel提供的Shell环境中的所有命令都是由Busybox提供的。关于Busybox，东西实在很多，有机会慢慢说。

    所以，这一行实际上的操作是把指定外的可执行文件包含到了Kdump Kernel之中。这样就能在Kdump Kernel之中使用很多你需要的程序了，比如lftp！

    6) disk_timeout 30这个没有用过，所以不好乱说

    7) extra_modules gfs2这个也是非常有意思的东西，可以把你需要的额外的内核模块包含进来。关于这个，我会再写一篇文章详细说明的。

    8) default shell这个是用来指定默认操作的。比如说，我使用了如下的配置：

core_collector makedumpfile --error

    很明显，makedumpfile没有--error这个参数选项。这会导致makedumpfile失败，Kdump Kernel在遇到这种情况的时候，就会根据default的选项，做相应的操作。这里设置的是shell，那么Kdump Kernel就会Drop到Shell去。你可以查看网络情况，使用Busybox提供的一些命令。

    default这个配置，除了shell之外，还可以设置为：reboot和halt。

    这就是大概的kdump的配置了，说的不是很细致。贴一个我自己使用的Kdump.conf

[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 shell

ext4 UUID=2c560b75-fc2b-4346-a669-6403e954498a

path /var/kdump

core_collector makedumpfile -c -d 31

default shell

Tips:

如往常一样，一些文档提供：

1) Busybox 的项目主页

2) man kdump.conf

3) /sbin/makedumpfile --help

4) man mkdumprd

六：Kdump一些琐碎的东西

    Kdump讲的差不多了，还有一些琐碎的东西要说。首先就是blacklist这个Feature：

    查看/sbin/mkdumprd这个文件，可以看到很多函数。先说明一下，/sbin/mkdumprd是个shell的脚本，如果对脚本不熟悉的话，可能难以理解。Shell在Linux下是非常非常强大的，这是后话了，先看看这个函数：

do_blacklist()

{

    local modName=$1

    if echo "$modName" | grep -q "\/" ; then

        local dirName="/lib/modules/$kernel/$modName"

        find $dirName -xtype f -exec basename {} \; | sed "s/^\(.*\).ko/blacklist \1/g" >> $MNTIMAGE/etc/blacklist-kdump.conf

    else

        echo "blacklist $modName" >> $MNTIMAGE/etc/blacklist-kdump.conf

    fi

}

    这个函数就是实现blacklist这个Feature的。这个Feature的大致目的就是，如果你不希望一些内核模块在Crash Kernel中被加载的话，可以在/etc/kdump.conf添加这样一行：

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_val

            case $DEFAULT_ACTION in

                reboot|shell)

                        FINAL_ACTION="reboot -f"

                        ;;

                halt)

                        FINAL_ACTION="halt -f"

                        ;;

                poweroff)

                        FINAL_ACTION="poweroff -f"

                        ;;

            esac

            ;;

    其实还有poweroff这个选项的。当然了，你还能做的更多，比如说手动添加一个启动到Single的模式！看吧，这就是看源码的好处，总能有很多新的发现^_^

    Kdump的学习差不多就这些了，当然还有更多更多的深层次的东西，比如说kexec的机制、mkdumprd脚本等等。还有很长的路要走......

七：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。开启这个选项可以：

echo 1 > /proc/sys/kernel/unknown_nmi_panic

        需要注意的是，启用这个特性的话，是不能够同时启用NMI_WATCHDOG的！否则系统会Panic！！！

    5) Force-crash

        最后，也是实验需要用的方法。强制触发一个Crash：

[root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger 

        需要注意的是，一旦你这么做了，你的系统就死了！所以，如果你已经保存好你的数据了，并且不担心原地复活过程中SELinux可能的Relabel的话，同时非常冒险、学习的精神！那你可以敲下回车了！

    6) PPC还有一些别的方法，就不细说了，还是以ix86和x86_64为主，如果有需要，请Mail、留言、谷老师！

    先贴一下我的配置文件，首先是/boot/grub/grub.conf：

[root@Derek-Laptop derek]# cat /boot/grub/grub.conf 

default=0

timeout=3

splashimage=(hd0,0)/grub/splash.xpm.gz

hiddenmenu

title 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=256M

initrd /initramfs-2.6.34.6-54.fc13.i686.PAE.img

    然后是/etc/kdump.conf：

[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 shell

ext4 UUID=2c560b75-fc2b-4346-a669-6403e954498a

path /var/kdump

core_collector makedumpfile -c --message-level 1 -d 31

default shell

    手动强制触发Kdump之前，确认一下Kdump服务：

[root@Derek-Laptop derek]# service kdump status

Kdump is operational

    如果你的不是operational，建议你别回车，否则，你的Fedora就真的死了！
    现在，可以敲下回车了！短暂的花屏、神秘字符之后，会出现很多信息了！具体的我就不贴出来了，也没办法贴，因为那个时候已经没有办法复制了！

    在这个过程之中，眼睛好使的话，能够看到trigger a crash这样的信息的，还能看到Crash Kernel启动的很多信息，比如说加载模块、等待磁盘准备、等待网络设备、挂载分区等等很多信息，跟Primary Kernel启动的时候是一样的！如果顺利的话，很快就能保存好vmcore，重启电脑了！这个时候需要插一句，如果你没有使用-d选项，那么你是多大的内存就会完整的保存多大的vmcore。根据需要选择自己的filter Level吧！

    重启完成之后，就能回到死而复生的Fedora了！如果你跟我一样，2GB的内存，使用-d 31的级别，不是那么老古董的机子，并且没有遇到SELinux的Relabel的话，估计5分钟就能完成了。

    现在来看看我的成果吧：

[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

    成功保存了vmcore，好好保留这个文件，以后还指望他分析出当初Crash的原因呢！

八：Crash初步

    最近有点忙，很久都没有写东西了！翻了一下专辑，上次写到了Crash，这篇是讲Crash初步的东西。

    首先得有一个vmcore，可以直接Dump，也可以Mail我o(∩∩)o...

[root@Derek-Laptop derek]# du -sh /var/kdump/127.0.0.1-2010-10-04-16\:14\:09/vmcore 

45M /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore

    这就是我的vmcore了，总共才45M，Level为31。我的内存为2GB，压缩之后的大小非常客观吧！不过还是根据自己的需要来调整Level吧！

    使用Crash来分析vmcore有好几种方法，可以help一下：

    第一种就是 ，跑在Live的系统上，例如：

       $ crash

      $ crash /usr/tmp/vmlinux

      $ crash /boot/System.map vmlinux.dbg

      $ crash -S vmlinux.dbg

      $ crash vmlinux vmlinux.dbg

    另外一种就是跑在dumpfile之上，例如：

      $ crash vmlinux vmcore

      $ crash /boot/System.map vmlinux.dbg vmcore

      $ crash -S vmlinux.dbg vmcore

      $ crash vmlinux vmlinux.dbg vmcore

     这里的-S表示 使用 /boot/System.map 作为mapfile。所有的Usage为：

Usage:

  crash [-h [opt]][-v][-s][-i file][-d num] [-S] [mapfile] [namelist] [dumpfile]

    我们这里采用的是跑在dumpfile之上的，所以需要安装一个包：

[root@Derek-Laptop derek]# yum install kernel-debuginfo

     需要注意的是，Kdump产生的vmcore需要对应的kernel-debuginfo才能使用Crash分析，所以需要安装对应的debuginfo！！！

     罗嗦了这么多，也该进入正题了！

[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/vmlinux 

crash 5.0.7

Copyright (C) 2002-2010  Red Hat, Inc.

Copyright (C) 2004, 2005, 2006  IBM Corporation

Copyright (C) 1999-2006  Hewlett-Packard Co

Copyright (C) 2005, 2006  Fujitsu Limited

Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.

Copyright (C) 2005  NEC Corporation

Copyright (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 under

certain conditions.  Enter "help copying" to see the conditions.

This program has absolutely no warranty.  Enter "help warranty" for details.

 

GNU gdb (GDB) 7.0

Copyright (C) 2009 Free Software Foundation, Inc.

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This 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/vmlinux

    DUMPFILE: /var/kdump/127.0.0.1-2010-10-04-16:14:09/vmcore  [PARTIAL DUMP]

        CPUS: 2

        DATE: Mon Oct  4 16:13:36 2010

      UPTIME: 00:32:28

LOAD AVERAGE: 0.94, 0.65, 0.41

       TASKS: 328

    NODENAME: Derek-Laptop

     RELEASE: 2.6.34.7-56.fc13.i686.PAE

     VERSION: #1 SMP Wed Sep 15 03:27:15 UTC 2010

     MACHINE: i686  (1662 Mhz)

      MEMORY: 2 GB

       PANIC: "Oops: 0002 [#1] SMP " (check log for details)

         PID: 3347

     COMMAND: "bash"

        TASK: efcb4c80  [THREAD_INFO: efcca000]

         CPU: 0

       STATE: TASK_RUNNING (PANIC)

crash> 

    Crash使用了对应的vmlinux来分析保存的vmcore，同时也打印出了一些信息^_^

    下面就是一些Debug工作了，比如说bt命令：

crash> bt

PID: 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 c07a3a65

    EAX: 00000063  EBX: 00000063  ECX: c0aa4e08  EDX: 00000000  EBP: efccbf14 

    DS:  007b      ESI: c09c171c  ES:  007b      EDI: 00000003  GS:  00e0

    CS:  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 c0408c98

    EAX: 00000004  EBX: 00000001  ECX: b7835000  EDX: 00000002 

    DS:  007b      ESI: 00000002  ES:  007b      EDI: b7835000

    SS:  007b      ESP: bfc9b1bc  EBP: bfc9b1f4  GS:  0033

    CS:  0073      EIP: 00898424  ERR: 00000004  EFLAGS: 00200246

    可以看到，内核崩溃的元凶就是 bash 了！因为我使用了

[root@Derek-Laptop derek]# echo c > /proc/sysrq-trigger

    除此之外，还可以看到当时的程序栈，相当底层的东西了吧^_^