红帽Linux故障定位技术详解与实例(3)

红帽Linux故障定位技术详解与实例(3)

 

在线故障定位就是在故障发生时, 故障所处的操作系统环境仍然可以访问，故障处理人员可通过console, ssh等方式登录到操作系统上，在shell上执行各种操作命令或测试程序的方式对故障环境进行观察，分析，测试，以定位出故障发生的原因。

AD：2014WOT全球软件技术峰会北京站 课程视频发布

 

5、用kdump工具内核故障定位实例

A) 部署Kdump

部署 kdump 收集故障信息的步骤如下:

（1）设置好相关的内核启动参数

在 /boot/grub/menu.lst 中加入如下内容

  1. crashkernel=128M@16M nmi_watchdog=1 

其中crashkernel参数是用来为kdump的内核预留内存的; nmi_watchdog=1 是用来激活NMI中断的, 我们在未确定故障是否关闭了中断的情况下, 需要部署NMI watchdog才能确保触发panic. 重启系统确保设置生效

（2）设置好相关的sysctl内核参数

在/etc/sysctl.conf 中最后加入一行

  1. kernel.softlookup_panic = 1  

该设置确保softlock发生时会调用panic, 从而触发kdump行为执行 #>sysctl -p 确保设置生效

（3）配置 /etc/kdump.conf

在 /etc/kdump.conf 中加入如下几行内容

  1. ext3 /dev/sdb1  
  2. core-collector makedumpfile -c –message-level 7 -d 31 -i /mnt/vmcoreinfo  
  3. path /var/crash  
  4. default reboot 

其中 /dev/sdb1 是用于放置dumpfile 的文件系统, dumpfile 文件放置在/var/crash下， 要事先在/dev/sdb1分区下创建/var/crash 目录. “-d 31”指定对dump内容的过滤级别，这参数对于dump分区放不下全部内存内容或用户不想让dumping中断业务太长时间时很重要. vmcoreinfo 文件放置在 /dev/sdb1 分区的 / 目录下, 需要使用如下命令产生:

#>makedumpfile -g //vmcoreinfo -x /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux

“vmlinux” 文件是由kernel-debuginfo 包提供的，在运行makedumpfile 之前需要安装相应内核的 kernel-debuginfo 和 kernel-debuginfo-common 两个包，该两个包需从 http://ftp.redhat.com 下载. “default reboot” 用来告诉kdump, 收集完dump信息后重启系统

(4)激活kdump

运行 #>service kdump start 命令，你会看到，在成功完成的情况下会在/boot/目录下生成一个initrd-2.6.18-128.el5.x86_64kdump.img 文件，该文件就是kdump加载的内核的 initrd文件，收集dump信息的工作就是在该initrd的启动环境下进行的. 查看/etc/init.d/kdump脚本的代码，你可看到其中会调用mkdumprd命令创建用于dump的initrd文件

1、测试Kdump部署的有效性

为了测试kdump部署的有效性，本人写了如下一个内核模块，通过insmod 加载该内核模块， 就能产生一个内核线程，在10秒左右后，占据100%的CPU，在20秒左右后触发kdump. 系统重启后，检查/oracle分区/var/crash 目录下的内容，就能确认vmcore文件是否生成.

  1. Zqfthread.c #include   
  2. #include   
  3. #include   
  4. #include   
  5. #include   
  6. #include   
  7.  
  8. MODULE_AUTHOR("frzhang@redhat.com");   
  9. MODULE_DESCRIPTION("A module to test ....");   
  10. MODULE_LICENSE("GPL");   
  11.  
  12. static struct task_struct *zqf_thread;   
  13. static int zqfd_thread(void *data);   
  14.  
  15. static int zqfd_thread(void *data)   
  16. {   
  17. int i=0;   
  18.  
  19. while (!kthread_should_stop()) {   
  20. i++;   
  21. if ( i < 10 ) {   
  22. msleep_interruptible(1000);   
  23. printk("%d seconds\n", i);   
  24. }   
  25. if ( i == 1000 ) // Running in the kernel   
  26. i = 11 ;   
  27. }   
  28. return 0;   
  29. }   
  30. static int __init zqfinit(void)   
  31. {   
  32. struct task_struct *p;   
  33.  
  34. p = kthread_create(zqfd_thread, NULL,"%s","zqfd");   
  35.  
  36. if ( p ) {   
  37. zqf_thread = p;   
  38. wake_up_process(zqf_thread); // actually start it up   
  39. return(0);   
  40. }   
  41.  
  42. return(-1);   
  43. }   
  44.  
  45. static void __exit zqffini(void)   
  46. {   
  47. kthread_stop(zqf_thread);   
  48. }   
  49.  
  50. module_init(zqfinit);   
  51. module_exit(zqffini)  
  52.  
  53. Makefile obj-m += zqfthread.o  
  54. Making #> make -C /usr/src/kernels/2.6.32-71.el6.x86_64/ M=`pwd` modules 

2、用crash 工具分析vmcore 文件

用crash 命令分析vmcore 的命令行格式如下所示. 用crash打开vmcore后，主要是用dmesg及 bt 命令打印出问题的执行路径的call trace, 用dis 反汇编出代码，最终确认call trace对应的C源码中的位置，再进行逻辑分析.

  1. #>crash /usr/lib/debug/lib/modules/2.6.18-128.el5.x86_64/vmlinux /boot/System.map-2.6.18-128.el5.x86_64 ./vmcore 

 

posted @ 2014-09-09 22:33  kissing狐  阅读(560)  评论(0)  编辑  收藏  举报