内核崩溃不再头疼：Linux crash工具从入门到实战全指南-优快云博客

内核崩溃不再头疼：Linux crash工具从入门到实战全指南

【免费下载链接】linux Linux kernel source tree 项目地址: https://gitcode.com/GitHub_Trending/li/linux

当服务器突然宕机、应用程序无响应时，如何快速定位内核崩溃原因？作为系统管理员和运维工程师，你是否曾因缺乏有效的内存转储分析工具而束手无策？本文将带你掌握Linux内核调试的得力工具——crash工具，通过实战案例学会内存转储分析，轻松解决90%的内核崩溃问题。读完本文你将获得：内存转储配置方法、crash工具核心命令使用、堆栈追踪与进程分析技巧，以及内核崩溃的完整排查流程。

一、crash工具与内核转储基础

1.1 什么是crash工具？

crash工具是Linux内核崩溃分析的专业工具，能够解析内核内存转储文件（kdump）并提供交互式调试环境。它允许用户检查内核数据结构、进程状态、内存信息等关键数据，是定位内核崩溃、死锁等严重问题的必备工具。该工具的核心功能在Documentation/admin-guide/kdump/gdbmacros.txt中有详细定义，包含了堆栈追踪、进程分析等实用宏定义。

1.2 内核转储（kdump）工作原理

内核转储机制通过在系统崩溃时捕获内存快照，为事后分析提供数据。其工作流程如下：

系统正常运行时预留一部分内存用于崩溃内核
发生崩溃时，kexec启动预留内存中的崩溃内核
崩溃内核将内存数据写入转储文件（默认路径/var/crash）
使用crash工具分析转储文件定位问题

配置内核参数时需添加crashkernel=size@offset参数，如crashkernel=512M@16M表示预留512MB内存用于崩溃内核，具体参数说明可参考Documentation/admin-guide/kernel-parameters.txt。

二、环境准备与配置

2.1 安装crash工具

在主流Linux发行版中，可通过包管理器直接安装crash工具：

# Debian/Ubuntu系统
sudo apt-get install crash

# RHEL/CentOS系统
sudo yum install crash

2.2 配置kdump服务

编辑grub配置文件，添加内核参数：

sudo vim /etc/default/grub
# 添加 crashkernel=auto 到 GRUB_CMDLINE_LINUX
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"

更新grub配置并重启：

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo systemctl enable kdump.service
sudo reboot

验证kdump服务状态：

sudo systemctl status kdump.service

三、crash工具核心功能实战

3.1 加载内核转储文件

使用crash工具分析转储文件的基本命令格式：

crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-2025-10-03-00:17/vmcore

其中：

vmlinux是带调试信息的内核镜像
vmcore是内存转储文件

3.2 常用调试命令

3.2.1 查看系统信息（sys）

crash> sys
      KERNEL: /usr/lib/debug/lib/modules/5.14.0-1.el8.x86_64/vmlinux
    DUMPFILE: /var/crash/127.0.0.1-2025-10-03-00:17/vmcore  [PARTIAL DUMP]
        CPUS: 8
        DATE: Fri Oct  3 00:17:39 2025
      UPTIME: 00:42:18
LOAD AVERAGE: 0.85, 0.92, 0.78
       TASKS: 326
    NODENAME: localhost.localdomain
     RELEASE: 5.14.0-1.el8.x86_64
     VERSION: #1 SMP Fri Sep 1 12:34:56 UTC 2025
     MACHINE: x86_64  (2800 MHz)
      MEMORY: 15.5 GB
       PANIC: "Oops: 0002 [#1] SMP PTI"
         PID: 1234
     COMMAND: "stress-ng"
        TASK: ffff888034567890  (nid: 0, pid: 1234)
         CPU: 3
       STATE: TASK_RUNNING (PANIC)

3.2.2 进程状态分析（ps）

列出所有进程状态：

crash> ps
   PID    PPID  CPU       TASK        ST  %MEM     VSZ     RSS  COMM
     1       0   0  ffff888034560000  IN   0.1  193884   12348  systemd
     2       0   0  ffff888034561800  IN   0.0       0       0  kthreadd
     3       2   0  ffff888034563000  IN   0.0       0       0  rcu_gp
   ...     ... ...  ...              ..   ...     ...     ...  ...
  1234     567   3  ffff888034567890  RU   0.5  204800  102400  stress-ng

3.2.3 堆栈追踪（bt）

查看崩溃进程的堆栈信息：

crash> bt 1234
PID: 1234   TASK: ffff888034567890  CPU: 3   COMMAND: "stress-ng"
 #0 [ffffc90000567c00] machine_kexec at ffffffff81067890
 #1 [ffffc90000567c60] __crash_kexec at ffffffff81123456
 #2 [ffffc90000567d30] crash_kexec at ffffffff81123567
 #3 [ffffc90000567d48] oops_end at ffffffff81005678
 #4 [ffffc90000567d70] no_context at ffffffff81067890
 #5 [ffffc90000567dc0] __bad_area_nosemaphore at ffffffff81067abc
 #6 [ffffc90000567e20] bad_area_nosemaphore at ffffffff81067def
 #7 [ffffc90000567e30] __do_page_fault at ffffffff81068123
 #8 [ffffc90000567e90] do_page_fault at ffffffff81068456
 #9 [ffffc90000567ec0] page_fault at ffffffff81f01234
    [exception RIP: stress_ng_vm_func+0x123]
    RIP: ffffffff81234567  RSP: ffffc90000567f78  RFLAGS: 00010246
    RAX: 0000000000000000  RBX: 0000000000000000  RCX: 0000000000000000
    RDX: 0000000000000000  RSI: 0000000000000000  RDI: 0000000000000000
    RBP: ffffc90000567fb0   R8: 0000000000000000   R9: 0000000000000000
   R10: 0000000000000000  R11: 0000000000000000  R12: 0000000000000000
   R13: 0000000000000000  R14: 0000000000000000  R15: 0000000000000000
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
#10 [ffffc90000567fb8] stress_ng_vm at ffffffff81234abc
#11 [ffffc90000567fd8] stress_ng_func at ffffffff81234def
#12 [ffffc90000567ff0] kthread at ffffffff8106a123
#13 [ffffc90000567ff8] ret_from_fork at ffffffff81f01456

3.3 高级调试技巧

3.3.1 查看内核数据结构

使用struct命令查看内核数据结构定义：

crash> struct task_struct
struct task_struct {
  volatile long state;        /* 0x0 */
  void *stack;                /* 0x8 */
  atomic_t usage;             /* 0x10 */
  unsigned int flags;         /* 0x14 */
  unsigned int ptrace;        /* 0x18 */
  ...
}

3.3.2 内存数据查看（x）

查看指定内存地址的内容：

crash> x/10xw ffff888034567890
ffff888034567890: 00000003 00000000 ffff8880 34567890 00000000 00000000 00000000 00000000
ffff8880345678b0: 00000000 00000000

3.3.3 日志信息查看（dmesg）

通过crash工具查看内核日志：

crash> dmesg
[    0.000000] Linux version 5.14.0-1.el8.x86_64 (mockbuild@) (gcc version 8.5.0 20210514 (Red Hat 8.5.0-3) (GCC)) #1 SMP Fri Sep 1 12:34:56 UTC 2025
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-5.14.0-1.el8.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rhgb quiet
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
...
[  252.123456] BUG: Bad page state in process stress-ng  pfn:12345
[  252.123457] page:ffffea0001234567 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0
[  252.123458] flags: 0x1000000000000000(zone=0)
[  252.123459] raw: 1000000000000000 dead000000000100 dead000000000200 ffff888034567890
[  252.123460] page dumped because: bad refcount
[  252.123461] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink ...
[  252.123462] CPU: 3 PID: 1234 Comm: stress-ng Tainted: G        W         5.14.0-1.el8.x86_64 #1
[  252.123463] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/22/2020
[  252.123464] Call Trace:
[  252.123465]  dump_stack_lvl+0x34/0x48
[  252.123466]  bad_page.cold+0x80/0xbd
[  252.123467]  free_pages_prepare+0x1f0/0x200
[  252.123468]  __free_pages+0x16/0x50
[  252.123469]  stress_ng_vm_func+0x123/0x200 [stress_ng]
[  252.123470]  stress_ng_vm+0xab/0x100 [stress_ng]
[  252.123471]  stress_ng_func+0xef/0x200 [stress_ng]
[  252.123472]  kthread+0x123/0x140
[  252.123473]  ret_from_fork+0x1f/0x30
[  252.123474] Mem-Info:
...

四、常见问题分析案例

4.1 空指针解引用导致崩溃

症状：内核日志中出现Oops: 0002 [#1] SMP PTI错误，堆栈中显示在某函数中访问了空指针。

分析步骤：

使用bt命令查看崩溃堆栈，确定出错函数
使用dis命令反汇编该函数，定位空指针访问位置
结合源码分析为何指针为空

4.2 内存泄漏问题

症状：系统运行一段时间后内存占用持续增长，最终OOM（内存溢出）。

分析步骤：

收集多个时间点的内存转储文件
使用slabtop命令比较 slab 分配器状态
使用pfiles命令查看进程打开文件情况
使用vmstat命令分析内存使用趋势

五、总结与进阶学习

5.1 关键知识点回顾

crash工具是内核崩溃分析的核心工具，需掌握其基本命令和高级调试技巧
内核转储（kdump）配置是前提，正确设置crashkernel参数至关重要
堆栈追踪（bt）、进程分析（ps）、内存查看（x）是定位问题的三大法宝

5.2 进阶学习资源

官方文档：Documentation/admin-guide/kdump/gdbmacros.txt
内核参数参考：Documentation/admin-guide/kernel-parameters.txt
内核源码调试：通过阅读init/main.c等核心文件深入理解内核启动流程

掌握crash工具不仅能帮助你快速解决内核崩溃问题，更能加深对Linux内核工作原理的理解。建议在测试环境中刻意制造一些内核崩溃场景进行练习，以熟练掌握各种调试技巧。遇到复杂问题时，可结合内核源码和官方文档进行深入分析。

点赞+收藏本文，关注获取更多Linux内核调试实战技巧！下期将分享"内核死锁问题高级分析方法"，敬请期待。

【免费下载链接】linux Linux kernel source tree 项目地址: https://gitcode.com/GitHub_Trending/li/linux

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考