从mdb到crash

本文面向使用过Solaris的mdb但是没有使用过Linux的crash的同学。比如说我自己，mdb用了很多年，现在全面转向Linux平台，于是很好奇Linux有没有类似的工具。熟悉Solaris的同学都知道，事后分析crashdump或者在线调试操作系统内核的强大工具就是mdb。而在Linux (以CentOS为例)中，类似的工具则是crash。当然，mdb不支持源码级的调试，只支持汇编级的调试。而crash则支持源码级的调试，因为跟gdb结合得非常紧密。

$ man -s8 crash
NAME
       crash - Analyze Linux crash dump data or a live system

SYNOPSIS
       crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS]    (dumpfile form)
       crash [OPTION]... [NAMELIST]                         (live system form)
...<snip>...

mdb的使用比crash要简单一些，因为不需要自己安装NAMELIST。但crash比mdb要好的地方在于支持源码级调试。

下面将介绍如何在CentOS上使用crash分析一个crashdump文件。

第一次使用crash的感觉很蒙圈，因为搞不懂神马是NAMELIST。

注意：使用mdb进行live的调试，就不需要神马NAMELIST。很简单， -K（大K）只能在console上使用，可以让整个内核挂起。例如：

root# mdb -k    #<-- Live kernel
or 
root# mdb -K    #<-- kmdb

这种情况下只能问度娘和qwant（在家上不了Google）了，幸运的是找到了Red Hat Enterprise Linux 7 Kernel Crash Dump Guide。于是按照Guide的提示一步一步来。有关kdump的简介截图如下：

1. 检查kexec-tools是否已经安装

[root@idorax9 tmp]# rpm -q kexec-tools
kexec-tools-2.0.7-50.el7.x86_64

我用的是CentOS 7, 默认已安装。

2. 安装system-config-kdump

[root@idorax9 tmp]# rpm -q system-config-kdump
package system-config-kdump is not installed
[root@idorax9 tmp]# 
[root@idorax9 tmp]# yum install system-config-kdump

3. 通过GUI对kdump进行配置 (goto Applications->System Tools->Kernel crash dumps)

选Basic Settings -> Manual settings, 将New kdump Memory设置为128M, 其他都使用默认设置，然后点Apply

点击apply后，会遇到"Unable to handle kdump services"的错误，不用理会，接下来需要reboot

在reboot之前，查看一下kdump是否active，果然不是

[root@idorax9 tmp]# systemctl is-active kdump
failed

4. reboot

5. reboot后，再次检查kdump是否active，必须是啦

[root@idorax9 tmp]# systemctl is-active kdump
active

6. 创建一个crashdump (类似solaris的reboot -d)

[root@idorax9 tmp]# echo 1 > /proc/sys/kernel/sysrq
[root@idorax9 tmp]# echo c > /proc/sysrq-trigger

7. 系统重启回来后，查看/var/tmp/vmcore

8. 尝试使用crash分析vmcore

8.1 安装NAMELIST，首先得启用CentOS-Debuginfo.repo

[root@idorax9 tmp]# cp /etc/yum.repos.d/CentOS-Debuginfo.repo /tmp
[root@idorax9 tmp]# vi /etc/yum.repos.d/CentOS-Debuginfo.repo
[root@idorax9 tmp]# diff /tmp/CentOS-Debuginfo.repo /etc/yum.repos.d/CentOS-Debuginfo.repo
20c20
< enabled=0
---
> enabled=1

8.2 安装NAMELIST， 注意/usr/lib/debug下面的内容为空，在安装之前

[root@idorax9 tmp]# yum clean all
[root@idorax9 tmp]# yum makecache

[root@idorax9 tmp]# ls -lF /usr/lib/debug/
total 0
lrwxrwxrwx. 1 root root  7 May 31 20:33 bin -> usr/bin/
lrwxrwxrwx. 1 root root  7 May 31 20:33 lib -> usr/lib/
lrwxrwxrwx. 1 root root  9 May 31 20:33 lib64 -> usr/lib64/
lrwxrwxrwx. 1 root root  8 May 31 20:33 sbin -> usr/sbin/
drwxr-xr-x. 6 root root 65 May 31 20:33 usr/

[root@idorax9 tmp]# rpm -q kernel
kernel-3.10.0-514.el7.x86_64

# NOTE: The debuginfo should be kernel-debuginfo-3.10.0-514.el7.x86_64

[root@idorax9 tmp]# debuginfo-install kernel

# NOTE: It took about 20m to download kernel-debuginfo-3.10.0-514.el7.x86_64.rpm

8.3 安装完成NAMELIST后

[root@idorax9 tmp]# ls /usr/lib/debug/lib/modules/
3.10.0-514.el7.x86_64

8.4 开始分析vmcore

[root@idorax9 tmp]# NAMELIST=/usr/lib/debug/lib/modules/3.10.0-514.el7.x86_64/vmlinux
[root@idorax9 tmp]# VMCORE=/var/crash/127.0.0.1-2017-05-31-22:47:32/vmcore
[root@idorax9 tmp]# crash $NAMELIST $VMCORE

crash 7.1.5-2.el7
Copyright (C) 2002-2016  Red Hat, Inc.
...<snip>...............................................
This GDB was configured as "x86_64-unknown-linux-gnu"...

      KERNEL: /usr/lib/debug/lib/modules/3.10.0-514.el7.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2017-05-31-22:47:32/vmcore  [PARTIAL DUMP]
        CPUS: 1
        DATE: Wed May 31 22:47:29 2017
      UPTIME: 00:05:44
LOAD AVERAGE: 0.04, 0.41, 0.26
       TASKS: 368
    NODENAME: idorax9
     RELEASE: 3.10.0-514.el7.x86_64
     VERSION: #1 SMP Tue Nov 22 16:42:41 UTC 2016
     MACHINE: x86_64  (2195 Mhz)
      MEMORY: 1 GB
       PANIC: "SysRq : Trigger a crash"
         PID: 3408
     COMMAND: "bash"
        TASK: ffff88000a4b8fb0  [THREAD_INFO: ffff88003b564000]
         CPU: 0
       STATE: TASK_RUNNING (SYSRQ)

crash> 

终于进入crash> 的操作界面了！

NAMELIST就是/usr/lib/debug/lib/modules/3.10.0-514.el7.x86_64/vmlinux, 这也忒长了...Orz (不得不说，Linux在CLI易用性上比Solaris差远了)

o 看看Backtrace （用bt命令，mdb用$C）

o 再反汇编看看 (disas /m <mem addr>, 而mdb的语法是<mem addr>::dis)

结论： 显然，系统之所以panic，是因为向内存地址0x0处写入0x1。到此为止，我们从零开始，完整体验了一把使用crash工具定位Linux系统panic的root cause的全过程. 有关crash工具的使用及技术原理，请阅读后面列出的参考资料。（特别推荐参考资料6:Crash Dump Analysis）

扩展：Solaris/Linux的工具链对比

#	Solaris	Linux(CentOS)
1	cc	gcc
2	dbx	gdb
3	mdb	crash
4	dtrace	systemtab, ftrace, LTTng
5	truss	strace

 参考资料：

1. Red Hat Enterprise Linux 7 Kernel Crash Dump Guide

2. Analyzing Linux kernel crash dumps with crash - The one tutorial that has it all

3. http://elixir.free-electrons.com/linux/v4.12-rc3/source/Documentation/kdump/kdump.txt

4. https://github.com/crash-utility/crash

6. Crash Dump Analysis ： crash | mdb