1. 环境搭建与前提
1.1 明确目标与必要条件
Linux内核崩溃排查 的核心是获取可分析的转储（vmcore）并结合符号表进行定位。为此，你需要具备对服务器的 root 权限、可用的磁盘空间，以及为崩溃转储预留内存的能力。
在实际环境中，先确认目标机器的分区、内存和内核版本信息，确保后续步骤能够顺利进行。版本匹配与符号 是分析成功的关键之一。
1.2 为崩溃转储预留内存与引导参数
为了在崩溃时保存转储，需要在引导时通过 crashkernel 参数为崩溃转储分配保留内存。缺少这一步，转储文件将无法生成。
常见的做法是在引导配置中添加 crashkernel，如 256M、512M 甚至更多，具体取决于总内存与工作负载。
# Debian/Ubuntu（示例）：
sudo nano /etc/default/grub
# 将 crashkernel 参数添加到引导命令
GRUB_CMDLINE_LINUX="crashkernel=256M …"sudo update-grub# RHEL/CentOS（示例）
# 修改 /etc/default/grub 或 /etc/grub.d/ 相关配置后
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
编辑完成后，重启系统 以使新的引导参数生效，并在重启后通过 cat /proc/cmdline 验证 crashkernel 是否生效。
1.3 验证 kdump/崩溃转储工具的安装与启用
不同发行版对崩溃转储的实现略有差异，常见做法是使用 kdump（或 kdump-tools、crash 工具组合）来实现崩溃转储的收集与管理。
确保系统服务可用并设置为开机自启，以便在发生崩溃时自动进入转储模式。kdump.service 的状态要正常。
# 通用检查与启用示例
sudo systemctl status kdump.service || true
sudo systemctl enable --now kdump.service
2. kdump 的原理与配置要点
2.1 kdump 的工作原理概览
kdump 基于 kexec 将内核从崩溃点快速切换到一个专用的崩溃转储内核，以捕获 vmcore。随后将转储数据写入磁盘或网络存储，供后续分析使用。
在崩溃时，思路是尽量让转储内核的工作时间最短，以避免二次崩溃，并确保转储目录具备足够空间与正确的权限。
2.2 配置要点与常见参数
关键配置包括为 crashkernel 分配内存、设置转储文件的保存路径、以及确定是否将转储通过网络导出。默认路径 /var/crash 通常是优先选择的落地位置。
# 查看当前内核命令行参数
grep -i crash /proc/cmdline# 验证 /var/crash 的写入权限
sudo touch /var/crash/.kdump_test && sudo rm /var/crash/.kdump_test
2.3 触发测试性崩溃以验证配置
在测试环境中可以通过系统对 SysRq 的触发来模拟崩溃，从而验证转储流程是否能正常工作。请务必在非生产环境进行此操作。
# 开启崩溃测试（谨慎使用，生产环境请勿执行以下测试）
echo 1 | sudo tee /proc/sys/kernel/panic_on_oops
echo c | sudo tee /proc/sysrq-trigger
测试后应检查 /var/crash 目录是否生成了转储文件，以及 dmesg/journal 日志中是否记录了转储过程。
3. crash 工具的安装与使用
3.1 crash 工具的作用与依赖
crash 是一个专门用于分析 Linux 内核崩溃转储的用户态调试工具，它需要与内核调试符号（如 System.map 和内核调试符号包）配合使用，才能正确解析内核地址与符号。
在不同发行版中，安装方式略有差异，通常需要先安装 crash，再安装对应版本的调试符号包。
3.2 安装 crash 与符号包
以下给出常见发行版的安装参考。实际环境请以你的发行版仓库为准。
# Debian/Ubuntu 示例
sudo apt update
sudo apt install crash
# 同步安装当前内核的调试符号（版本相关，请按实际情况操作）
sudo apt install linux-image-$(uname -r)-dbg# RHEL/CentOS 示例（DNF/YUM 皆可）
sudo dnf install crash kernel-debuginfo-$(uname -r)
安装完成后，确保 crash 能找到 System.map 文件，以及 vmcore 的路径。系统符号文件的缺失将导致无法正确解码栈回溯。
3.3 使用 crash 进行初步分析
在崩溃转储文件准备就绪后，可以通过 crash 会话进入分析阶段。若 vmcore 文件位于 /var/crash，可按如下方式启动分析：
# 启动 crash 会话（示例， 指具体 vmcore 路径， 为对应内核的 System.map）
sudo crash /var/crash/vmcore-$(date +%F-%T) /boot/System.map-$(uname -r)
进入 crash 提示符后，常用的分析命令包括查看线程、获取栈帧、定位崩溃点等。例如：bt（backtrace）、ps（查看进程）、以及查看变量的数值。
# 崩溃分析常用命令示例（在 crash 提示符中）
crash> bt
crash> ps
crash> 'node_name' # 根据需要跳转到具体符号
crash> help
4. 实战排查流程与要点
4.1 确认崩溃可用性与转储路径
第一步是确认 crashkernel 已正确分配、kdump 服务正常工作，并且转储文件能够落地到配置的路径。若没有转储，排查点主要集中在引导参数、kdump 服务状态、以及磁盘权限。
在排查时，优先检查系统日志中关于崩溃转储的记录，尤其是崩溃发生时的系统事件和转储完成的时间点。
4.2 触发崩溃并验证转储产出
通过安全的测试环境触发崩溃后，检查 /var/crash 或自定义落地路径是否产生了 vmcore 文件，以及是否更新了系统日志中的转储信息。
# 触发测试性崩溃（仅测试环境）
echo 1 | sudo tee /proc/sys/kernel/panic_on_oops
echo c | sudo tee /proc/sysrq-trigger# 验证转储输出
ls -lah /var/crash
4.3 结合 dmesg / journal 进行快速定位
在崩溃前后的内核日志中通常会包含崩溃原因、驱动/模块信息以及核心线程的调用栈。结合 dmesg 与 journalctl 的时间线，可以快速缩小定位范围。
# 查看最近的内核日志
dmesg -T | tail -n 200# 使用 journald 查看最近的内核相关日志
journalctl -k -n 200 --no-pager
4.4 使用 crash 进行深层栈分析
在 crash 会话中，使用 bt、ps、以及符号表辅助下的定位，可以找到崩溃点所在的函数及执行路径。
# crash 会话中的深度分析示例
crash> bt
crash> ps
crash> foreach vaddr do
crash> end
当符号表可用时，崩溃栈通常能够映射到具体的内核函数与驱动模块。此处建议将结果整理成可追踪的问题清单，以便后续修复工作。
5. 常见场景与故障处理
5.1 缺失的符号导致的分析困难
若 System.map 或调试符号不匹配，crash 的解析将变得困难甚至不可用。此时的关键是确保 vmcore 与 System.map 匹配，并尽快安装对应版本的符号包。
5.2 崩溃但未生成转储
常见原因包括 crashkernel 未正确分配、kdump 未启用、/var/crash 权限问题，以及转储目标磁盘已满。先检查引导参数、kdump 服务状态，以及磁盘空间。
# 确认磁盘空间
df -h /var/crash# 确认 crashkernel 是否已分配
grep -i crash /proc/cmdline
5.3 硬件驱动导致的崩溃定位
若崩溃点在厂商驱动或特定硬件模块，建议收集驱动版本、固件版本及硬件信息，并在 crash 的结果中定位到具体驱动函数名。此时内核源码与驱动版表 是后续修复的依据。
5.4 虚拟化环境下的崩溃排查
虚拟化环境中，崩溃可能受宿主机与客机共享资源的影响。确保 虚拟化平台的转储集成与网络传输 能够正确传递 vmcore，同时关注 Guest OS 与 Host OS 的日志对照分析。
5.5 自动化与持续集成场景
在持续集成/持续交付流程中，可以将崩溃转储分析脚本化，自动提取关键符号、自动生成问题单，以及将结果推送到告警系统。确保流程中对崩溃转储的隐私与安全进行严格控制。
以上各节内容共同构成了一个完整的 Linux 内核崩溃排查全攻略，核心围绕 kdump 的崩溃转储机制与 crash 的离线分析工具展开。通过系统化的环境配置、精准的转储生成、以及高效的分析步骤，可以在最短时间内定位崩溃根因并实现快速修复。
