Linux 崩溃了，你能做什么？

公众号关注 「奇妙的 Linux 世界」

设为「星标」，每天带你玩转 Linux ！

Linux崩溃了，你能干什么

如果你发现你的Linux机器重启了，你能查出来是什么原因导致的吗。

绝大多数人是束手无策的，今天，本文（结合真实案例）教你怎么做。

一、首先你要有dump文件

接触过Linux的，大概知道有个core dump的，很多人以为这是核心转储，nonono，它是内存转储的意思，core来源于早年间磁芯存储器的那个磁芯（core）。

实现core dump机制有很多工具，kdump技术是目前最可靠、最常用的，已被主要的Linux厂商选用。当Linux内核崩溃时，kdump工具捕获当时内存等状态信息，生成转储文件（vmcore），保留现场证据，然后才重启。

当然，如果要用kdump，需要安装kdump工具、修改内核启动参数、修改kdump配置文件参数、启动kdump服务功能。

二、怎么解析dump文件

如果你装了kdump，Linux崩溃重启后，你会在/var/crash目录发现vmcore文件，恭喜你，你可以用它来发现根因了。

为了分析core dump，你需要安装crash工具，crash工具是RedHat公司提供的一个开源的内核分析工具，它在gdb的基础上实现了解析内核的功能。

你还需要安装Linux内核相应版本的debuginfo包，这个包安装好后会在操作系统上生成一个vmlinux文件，该文件包含完整的符号信息，用于提供调试信息。

三、怎么使用crash工具

crash工具包括了很多命令，包括查看内核日志的log命令、查看调用栈的bt命令、查看进程情况的ps命令、查看某个地址对应符号的sym命令、查看文件系统信息的files命令等。

总之，有了这个大杀器，你再有一点操作系统知识，有一点编程知识，就能干一般人干不了的事了。

比如，有一天，你发现你的若干台服务器意外重启了，你一脸懵，你的领导责令你务必找到根因。

你就可以悠然打开crash工具，来一趟探因之旅：

crash /usr/lib/debug/lib/modules/2.6.32-754.35.1.el6.x86_64/vmlinux  /var/crash/vmcore

上面那个vmlinux，是调试所需的内核镜像；上面那个vmcore，就是core dump。

四、用sys命令看看基本信息

用crash打开vmcore文件后，使用sys命令，你可以看到系统内核的基本信息，比如崩溃时系统中的进程数量、系统内核版本、内存大小、系统崩溃时的报错信息等。

比如，报错信息是：BUG: unable to handle kernel paging request at ffffffffa0395070

懂的人都懂，这是内核分页请求报错。

可能的原因是：错误的内存访问、内存不足、硬件故障等等。

当然最可能的是：错误的内存访问。

下面，我们用bt命令看看内核崩溃的调用栈信息。

所谓调用栈，就是谁调用了谁，谁又进一步调用了谁。

五、用bt命令查看进程信息

这一步是非常重要的，毕竟，我们非常想看到，机器是怎么一步步崩溃的。

使用crash工具的bt命令（栈跟踪backtrace的缩写）查看调用栈信息，显示信息如下：

crash> bt
第1行   PID: 177488  TASK: ffff880435b92ab0  CPU: 2   COMMAND: "ss"
第2行   #0 [ffff880437c0b7e0] machine_kexec at ffffffff8104179b
第3行   #1 [ffff880437c0b840] crash_kexec at ffffffff810d7a52
第4行   #2 [ffff880437c0b910] oops_end at ffffffff81560310
……
第10行   #8 [ffff880437c0bb40] page_fault at ffffffff8155f265
第11行      [exception RIP: strnlen+9]
第12行      RIP: ffffffff812ae3a9  RSP: ffff880437c0bbf8  RFLAGS: 00010286
……
第25行  #15 [ffff880437c0be70] proc_reg_read at ffffffff8120faf0
第26行  #16 [ffff880437c0bec0] vfs_read at ffffffff811a3447
第27行  #17 [ffff880437c0bf00] sys_read at ffffffff811a3791
第28行  #18 [ffff880437c0bf50] system_call_fastpath at ffffffff81566391

不用细看，bt在第一行就说了，崩溃就是“ss”这个程序引起的。从第28行开始，ss调用了system_call_fastpath、然后是sys_read（第27行）、然后是我这里省略了的一连串调用，然后是第10行令人胆战心惊的page_fault，然后是oops_end（哦，要完蛋了，第4行）、crash_kexec（准备kdump，第3行）、machine_kexec（调起一个新内核采集信息，第1行），然后kdump就生成了core dump文件：vmcore。

注意第25行，可以看出ss干了一件事，调用了proc_reg_read，这表明它读了proc文件系统。

proc是一个虚拟文件系统，提供了内核和进程的运行信息。

ss读proc文件是正常的，因为要读取一些内核层面的信息，但正是这个读，导致了崩溃。

注：ss是一个用于查看和分析Linux系统中的网络连接和套接字（socket）状态的工具。它是 netstat命令的替代品，通常比netstat更加高效和快速。

下面我们看看ss这个进程的具体信息。

六、用ps命令查看都有哪些进程

使用crash工具的ps命令查询内核崩溃前所有进程的状态信息。

比如：

crash> ps
PID    PPID    CPU        TASK           ST  %MEM  VSZ  RSS    COMM
...
177488 64302    1  ffff880436662ab0   RU   0.0  6280  568     ss
...

当然，崩溃时的进程有很多了，这里只显示ss进程，可以看到它的进程号为177488。

有了ss的进程信息，现在我们看看ss到底调用了哪个文件。

七、用files命令查看进程访问了哪个文件

一般是使用struct file命令查看某进程访问文件的信息。

刚才我们用ps命令查到ss的进程地址为ffff880436662ab0，用它作为struct file的输入参数。

crash> struct file.f_path ffff880436662ab0
  f_path = {
    mnt = 0xffff880432adbe80, 
    dentry = 0xffff880101cae5c0
  }

该命令显示了ss进程访问文件路径的结构信息，mnt表示文件所在的挂载点，dentry表示文件名在地址ffff880101cae5c0。

接下来使用files命令来解析这个dentry地址。

crash> files -d 0xffff880101cae5c0
     DENTRY           INODE           SUPERBLK     TYPE      PATH
ffff880101cae5c0 ffff880101c1d598 ffff88043a23e800 REG  /proc/slabinfo

此时可以得知，故障时，ss进程访问的文件是/proc/slabinfo。

注：/proc/slabinfo文件包含了当前内核中所有slab内存的详细信息。

八、使用sym命令看故障相关源码

从前面bt命令的调用栈信息看到，异常报错位置为[exception RIP: strnlen+9]（第11行），RIP指向异常调用地址为ffffffff812ae3a9（第12行）。

使用sym命令，看看这个异常地址是个啥。

crash> sym ffffffff812ae3a9
ffffffff812ae3a9 (T) strnlen+9 /usr/src/debug/kernel-2.6.32-754.35.1.el6/ linux-2.6.32-754.35.1.el6.x86_64/lib/string.c: 407

这个命令很牛，它告诉我们，这个异常地址，对应的源码（string.c）和行号（第407行）都告诉我们了。

我第一次见到这个的时候，不禁惊呼，这么牛啊，从内存dump能看出问题源码在哪？

对，就这么牛，kdump很牛，debuginfo也很牛，一个用于调试，一个提供调试信息，程序员不会亏待自己的。

注：当你调试一个内核时，需要安装对应版本的debuginfo包，如下：

debuginfo-install kernel-debuginfo-common-2.6.32-754.35.1.el6.x86_64.rpm

当然，看到源码并不稀奇，Linux是开源的嘛！（如果你玩Windows，如果机器崩溃了，那就崩溃了吧。）

这段完整代码如下：

size_t strlen(const char *s) {
  const char *sc;
  for (sc = s; *sc != '\0'; ++sc)/*这就是那个第407行*/;
  return sc - s;
}

这段代码通过for循环，从输入字符串初始字符s开始，遍历其所指的内容，循环直到遇到字符串结尾的空字符'\0'，最后返回字符串长度。

那个*sc就是读sc这个地址里的内容。

但是，读着读着，就崩溃了，因为读到翔了。

八、用log命令查更多的内容

使用log命令查到的信息如下：

crash> log
...
VMAGENTMOD: 3846: init_module: get into init_module, syshook_enable:1
VMAGENTMOD: 177350: cleanup_module: get into cleanup_module 
...

可以看出，内核崩溃前，有加载和卸载某个驱动模块的动作。相关的进程号是3846和177350。

经查询，这2个进程号都属于防病毒工具的进程。它调用的cleanup_module是内核函数，用于卸载驱动模块。

用crash的mod -t命令，显示内核模块加载的详细信息：

crash> mod -t
NAME           TAINTS
syshook_linux  (U)
vmsecmod       (U)

在log命令的输出中，还可以看到“[last unloaded: vmsecmod]”，这说明，内核最后卸载的驱动模块就是vmsecmod。

另外，防病毒工具的本地日志也显示，服务器重启前刚刚执行了停止防病毒进程的操作。

这些信息都告诉我们，这次崩溃的发生，防病毒工具有相当的嫌疑。

注：mod的-t选项，是显示taints信息。所谓taints（污点），是内核运行时的一个标志，用来指示内核在运行过程中遇到了某些潜在问题或非标准情况。如果taints是U，表明该模块是未经签名的，是用户开发的。

九、回到sys命令

我们最开始使用sys命令查到有如下的报错信息：

BUG: unable to handle kernel paging request at ffffffffa0395070

用sym命令看看这个地方到底是何方神圣。

crash> sym ffffffffa0395070
ffffffffa0395070 (r) hash_info_mempool_name [vmsecmod]

可以看到，这个地址来自vmsecmod驱动，对应的源码是hash_info_mempool_name。

现在基本可以判断出来是怎么回事：

防病毒工具申请并使用了slab分配器提供的内存，相关信息记录在/proc/slabinfo中，ss进程会去查询slabinfo，获取必要的信息。就是在访问slabinfo时，造成了内核崩溃。

有人在崩溃前卸载了防病毒的驱动，停止了防病毒服务，按道理，防病毒申请的slab内存应该也释放掉，slabinfo中也不会有对应信息。但是，ss进程居然还在访问这块数据，说明防病毒进程申请的slab内存未正常释放!

知识普及：slab主要用于内核态中的内存分配，可高效分配和管理小块内存。在/proc/slabinfo这个虚拟文件中，记录了系统中所有slab内存块的信息，如对象数量和内存使用量等。ss读取/proc/slabinfo，获取与网络套接字相关的内存使用和分配信息，提供详细的网络连接状态。 

九、原来是防病毒工具的bug

把上述信息给到防病毒厂商，他们的研发工程师分析确认，确实是防病毒客户端有bug，导致了这次重启。

bug很简单，就是在卸载vmsecmod驱动时，应该同步释放所申请的slab内存区，但程序员没有这么做。

在重启的服务器上，有服务器管理工具，它会定期调用ss命令，ss会读取slabinfo，防病毒没有释放slab内存，所以ss仍然可以读取slabinfo中的指针，该指针却指向了已经释放了内存区（vmsecmod驱动曾经用过的地方）。

由于指针指向的内存已经释放，所以这就是访问非法地址，其实就是分页机制无法将该地址映射到物理地址，此时处理器就会向操作系统发出一个“page fault”错误，如果处理器此时处于超级用户模式，系统就会产生一个Oops，哦，完蛋了。

注：如果在用户态访问了非法地址，那么，你大概会得到一个经典的Segmentation fault（初级程序员的噩梦）。

十、当时发生了什么？

那天，某个工程师做了一件事，更新防病毒工具的许可，这个防病毒工具是企业版的，有一个管理端，还有运行在若干台服务器上的防病毒客户端。

他先在防病毒管理端导入软件许可，接着管理端将软件许可分发给每台服务器上的客户端，由客户端本地更新许可文件。

在客户端更新许可文件时，会先停止防病毒客户端进程（更新完许可文件后，再启动进程），停止进程会导致vmsecmod驱动模块的卸载，由于有bug，清理动作不完善，残留了无主的slab内存。

而服务器上部署的自动化工具，会定时执行ss命令，ss遍历slabinfo信息时，读取了在野的指针，引发page fault，内核崩溃。

后记

Linux这么稳定的内核都会崩溃。

做一个内核稳定的人，很不容易呢。

注：本文是一个简单的介绍，相对完整的分析见《小白也能看懂的Linux崩溃分析大法》

本文转载自：「卫sir说」，原文：https://url.hi-linux.com/8dtUW，版权归原作者所有。欢迎投稿，投稿邮箱: editor@hi-linux.com。

🚀 最近，我们建立了一个技术交流微信群。目前群里已加入了不少行业内的大神，有兴趣的同学可以加入和我们一起交流技术，在 「奇妙的 Linux 世界」 公众号直接回复 「加群」 邀请你入群。

🌟『极客视界』科技达人必备综合资讯指南，等你来探索！访问网址 https://bestgeek.org 即可打开新世界。

📕 关注『奇妙的 Linux 世界』公众号，带你开启有趣新生活！更多好用好玩的软件资源，可访问 https://666666.dev 免费获取。

你可能还喜欢

点击下方图片即可阅读

ptcpdump: 新一代抓包神器，可捕获任何进程、容器或 Pod 的网络流量


点击上方图片，『美团|饿了么』外卖红包天天免费领

更多有趣的互联网新鲜事，关注「奇妙的互联网」视频号全了解！