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

参考 “#>man kdump。conf”， “#>man crash”， “#>man makedumpfile”学习怎样使用kdump和crash。 访问 http：//ftp。redhat。com可下载debuginfo文件

（2）用systemTap定位bug

systemtap 属于probe类的定位工具，它能对内核或用户代码的指定位置进行probe，当执行到指定位置或访问指定位置的数据时，用户定义的probe函数自动执行，可打印出该位置的调用堆栈，参数值，变量值等信息。 systemtap选择进行probe的位置很灵活，这是systemtap的强大功能所在。Systemtap的probe点可包括如下几个方面：

- 内核中全部系统调用，内核及模块中全部函数的入口或出口点 - 自定义的定时器probe点

- 内核中任意指定的代码或数据访问位置 - 特定用户进程中任意制定的代码或数据访问位置

- 各个功能子系统预先设置的若干probe点，如tcp，udp，nfs，signal各子系统都预先设置了很多探测点

systemTap的脚本用stap脚本语言来编写，脚本代码中调用stap提供的API进行统计，打印数据等工作，关于stap语言提供的API函数，参考 “#> man stapfuncs”。 关于systemTap的功能和使用可参考 “#> man stap”， “#> man stapprobes” （3）ftrace

ftrace 是linux内核中利用tracepoints基础设施实现的事件追踪机制，它的作用在于能比较清楚的给出在一定时间内系统或进程所执行的活动，如函数调用路径，进程切换流等。Ftrace可用于观察系统各部分的latency，以便进行实时应用的优化；它也可以通过记录一段时间内的内核活动来帮助故障定位。如用以下方法可trace某个进程在一端时间的函数调用情况 1. #> echo “function” > /sys/kernel/debug/tracing/current_tracer 2. #> echo “xxx” > /sys/kernel/debug/tracing/set_ftrace_pid 3. #> echo 1 > /sys/kernel/debug/tracing/tracing_enabled 除tracing函数调用外，ftrace还可tracing系统的进程切换，唤醒，块设备访问，内核数据结构分配等活动。注意，tracing和profile是不同的，tracing记录的是一段时间内的全部活动，而不是统计信息，用户可以通过/sys/kernel/debug/tracing下的buffer_size_kb设置缓冲区的大小，以记录更长时间的数据。 关于ftrace的具体使用可参考内核源码Documenation/trace下的内容 （4）oprofile 和 perf

oprofile和perf都是对系统进行profile（抽样，统计）的工具，它们主要用来解决系统和应用的性能问题。perf功能更强大，更全面，同时perf的用户空间工具和内核源码一起维护和发布，让用户能及时的享受perf内核新增加的特征。Perf 是在RHEL6中才有，RHEL5中没有Perf。Oprofile和perf 都使用现代CPU中具有的硬件计数器进行统计工作，但perf还可以使用内核中定义的 “software counter”及 “trace points”， 所以能做更多的工作。Oprofile的抽样工作利用 CPU的NMI中断来进行，而perf既可以利用NMI中断也可利用硬件计数器提供的周期性中断。用户能很容易用perf来oprofile一个进程或系统的执行时间分布，如 #> perf top -f 1000 -p 还可以利用系统定义的 “software counter”和各子系统的 “trace points” 对子系统进行分析，如 #>perf stat -a -e kmem:mm_page_alloc -e kmem:mm_page_free_direct -e kmem:mm_pagevec_free sleep 6 能统计6秒内kmem子系统的活动（这一点实际是利用ftrace提供的tracepoints来实现） 我认为有了perf，用户就没必要使用oprofile了 5、用kdump工具内核故障定位实例 A）部署Kdump

部署 kdump 收集故障信息的步骤如下： （1）设置好相关的内核启动参数 在 /boot/grub/menu.lst 中加入如下内容 crashkernel=128M@16M nmi_watchdog=1

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

（2）设置好相关的sysctl内核参数 在/etc/sysctl.conf 中最后加入一行 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(\ 9. MODULE_DESCRIPTION(\

10. MODULE_LICENSE(\

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(\

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,\

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源码中的位置，再进行逻辑分析。 #>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

6、使用kprobe来观察内核函数的执行实例

kprobe是SystemTap对内核函数进行probing的功能在内核中的实现，由于内核中提供了正式的API来使用kprobe，所以对很多内核程序员来说，也许直接使用kprobe比使用SystemTap更方便。内核中提供了三种类型的kprobe处理函数，分别是jprobe，kprobe，kretprobe，下面的代码用这三个probe观察在TCP/IP的arp_process函数执行中对

ip_route_input()调用的返回结果。这个代码还展示了在同一个函数probe的Entry handler和Ret handler之间共享参数的方法。代码如下： 1. arp_probe.c /* 2. * arp_probe.c, by Qianfeng Zhang (frzhang@redhat.com) 3. */ 4. 5. #include

百度搜索“77cn”或“免费范文网”即可找到本站免费阅读全部范文。收藏本站方便下次阅读，免费范文网，提供经典小说综合文库红帽Linux故障定位技术详解与实例(2)在线全文阅读。