linux 内核部分崩溃,Linux 系统内核崩溃分析处理简介

Written by

arstercz

-2019-11-12

Linux 系统内核崩溃分析处理简介

背景说明

目前绝大多数的 Linux 发行版都会将 kdump.service 服务默认开启, 以方便在内核崩溃的时候, 可以通过 kdump 服务提供的 kexec 机制快速的启用保留在内存中的第二个内核来收集并转储内核崩溃的日志信息(vmcore 等文件), 这种机制需要服务器硬件特性的支持, 不过现今常用的服务器系列均已支持.

如果没有特别设置, 系统都采用默认的 kdump 服务配置, 崩溃的日志文件默认以 disk 方式保存在本地的磁盘目录, Centos/Redhat 系列的系统主要保存在以下目录:

/var/crash/

一般生成的 vmcore 文件仅仅是内核崩溃时的一部分信息, 如果全部导出对磁盘和时间都是很大的消耗, 默认情况下, dump 的级别为 31, 仅导出内核态的数据, 详见 makedumpfile -d 选项. 这种情况下系统崩溃一般生成的 vmcore 文件大小受崩溃时内核占用的内存决定, 通常不会很大. 下面则主要介绍如何收集并简单分析这些 vmcore 文件.

目录列表

获取 vmcore

我们在主机中分析 vmcore 文件的时候需要系统安装对应内核版本的 debuginfo 安装包以便获取函数的符号信息. 以如下内核版本为例:

kernel-3.10.0-957.27.2.el7.x86_64 -- 系统内核版本

kernel-debuginfo-3.10.0-957.27.2.el7.x86_64 -- 安装对应的 debuginfo 版本

所以想要快速的分析 vmcore 文件大概可以采用以下两种方式:

1. 在出问题的机器中直接安装对应版本的 debuginfo 包;

2. 将 vmcore 文件推到指定的主机进行分析;

上面两种方式都需要在主机中安装 crash 工具, 第一种方式相对快速, 不过会修改服务的主机, 另外也不容易大范围的安装到线上的所有机器. 第二种方式较慢, 具体取决于传输的速度, 不过很适合对线上故障的汇总分析.

我们通常采用第二种方式, 可以修改 kdump 配置以 nfs 或 ssh 方式将生成的日志传到指定的机器, 也可以在问题主机重启后手动传到指定的机器. 当然主机间通信的速度要足够快, 崩溃日志传送完成后才会开始重启操作, 所以越慢就意味着机器正常重启需要的时间越长, 相应的从内核崩溃到可以简单的 crash 分析之间的时间间隔就越大.

分析 vmcore

安装 debuginfo 包的目的在于获取对应内核版