linux主机利用crash分析_var_crash_下的vmcore 的dump分析

当主机crash后，会在这个目录下生成vmcore，也就是dump，如何分析这个dump来定位宕机的原因呢?

可以执行crash vmlinux /var/crash/127.0.0.1-2014-06-22-16:08:36 来进入分析模式（vnlinux这里要指定的）

他会报错，原因应该是缺乏kernel-debuginfo包，我们安装下后再尝试：

要想crash可以分析core-dump，必须要安装这三个包：

安装完后，我们可以利用find / -name vmlinux

上面的crash爆出了：

报错，这是由于kernel-debuginfo-common-x86_64包的版本和本机内核版本不一致照成的。

（说下：要想使用crash，只要保证debuginfo的版本和你要分析的core的内核版本本机的kernel版本三者的版本必须一样，任意一个不一致都会导致不能分析dump）

#

#

选择包和版本

#

再选择show debug package

找到debug包 下载就可以了

----------------------------------------

然后安装一下：

#安装包开始

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++至于我们怎么知道coredump的内核版本，可以cd /var/crash/127.0.0.1---------/

然后执行

strings vmcore |grep 'OSRELEASE'

可以显示出vmcore的内核版本

顺便附一下内核版本和系统版本的对应关系

CentOS 6.0/RHEL6 Update 0 -------------------> 2.6.32-71

CentOS 6.1/RHEL6 Update 1 -------------------> 2.6.32-131

CentOS 6.2/RHEL6 Update 2 -------------------> 2.6.32-220

CentOS 6.3/RHEL6 Update 3 -------------------> 2.6.32-279

CentOS 6.4/RHEL6 Update 4 -------------------> 2.6.32-358

CentOS 6.5/RHEL6 Update 5 -------------------> 2.6.32-431

CentOS 6.6/RHEL6 Update 6 -------------------> 2.6.32-504

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #后再分析下dump

可以进crash模式了。

刚进crash的时候会有一个总揽：

KERNEL: 系统崩溃时运行的 kernel 文件

DUMPFILE: 内核转储文件

CPUS: 所在机器的 CPU 数量

DATE: 系统崩溃的时间

TASKS: 系统崩溃时内存中的任务数

NODENAME: 崩溃的系统主机名

RELEASE: 和 VERSION: 内核版本号

MACHINE: CPU 架构

MEMORY: 崩溃主机的物理内存

PANIC: 崩溃类型，常见的崩溃类型包括：

SysRq (System Request)：通过魔法组合键导致的系统崩溃，通常是测试使用。通过 echo c > /proc/sysrq-trigger，就可以触发系统崩溃。

oops：可以看成是内核级的 Segmentation Fault。应用程序如果进行了非法内存访问或执行了非法指令，会得到 Segfault 信号，一般行为是 coredump，应用程序也可以自己截获 Segfault 信号，行处理。如果内核自己犯了这自样的错误，则会弹出 oops 信息。

他会说明panic的原因。有些会很明显，比如：

然后可以执行swap查看宕机时的swap值：

有时候会内存过高：

也可以已在总揽上看当时的负载：

有时会很高：

另外还有bt指令，可以查看内核指令：

------说明下，bt是分析crash的很好的工具，以“# 数字”开头的行为调用堆栈，即系统崩溃前内核依次调用的一系列函数，通过这个可以迅速推断内核在何处崩溃，比如 这里的#1 crash_kexec at fffffffff81035b7b , 我们再可以利用dis -l 加内存地址来反汇编出内容

可以明显的看到

说明系统crash了，

是因为执行收到c的sysrq才宕的。

另外还有ps 命令,可以查看宕机时的系统进程状态。、

还有一个log命令，可以会安装crash前按时间顺序来分析的core内的log。

----------------------------------------------------------------------------------------------------------------------------

两天前电子渠道dmsapp16重启，有个dump产生，我看了下内容，panic的原因是空的。但是根据log及bt查看感觉问题定位是pid 0 swapper造成的，烦请让二线分析下，感谢。

bt的结果

log的结果（载入完内核模块后定位原因在pid0上）

想了解下panic原因为空是什么意思？

经二线分析，