简介这是一份面向Linux运维工程师与系统管理员的故障排查参考资料聚焦系统死机或崩溃后如何有效采集与分析现场信息帮助判断问题源于硬件故障还是应用程序缺陷。文档围绕Core dump、Diskdump、Netdump三种机制展开分别覆盖应用级内存转储、单机内核转储以及跨网络远程转储的配置思路与关键命令适合具备一定Linux基础、需要提升故障定位能力的读者参考。资源包共1个文件为doc格式文档压缩包约47KB内容紧凑、便于随查随用。目前已有527人学习下载说明其在运维排障场景中具有一定实用价值。读者可从中获得三类崩溃信息获取方式的完整梳理包括core文件生成路径设置、diskdump保留分区初始化与initrd重建、netdump服务端与客户端配置要点以及网卡netpoll支持判断等细节有助于在系统异常后快速留存关键现场数据缩短故障分析与修复周期。1. 线上 Linux 死机那一刻先别急着按电源键凌晨两点被告警叫醒SSH 连不上、ping 不通、业务全挂机房那边说机器还在通电但屏幕没有任何反应——这就是典型的 Linux 死机现场。很多人第一反应是长按电源键重启但这一按内存里的现场就全没了事后想复盘到底是 OOM、IO hang 还是内核 panic只能靠猜。Linux 死机处理的核心不是「怎么重启」而是「在重启之前尽可能把现场信息捞出来同时判断这次死机属于哪一类」。这篇笔记面向的是真正管过线上服务器的人你手上有 root、有 IPMI 或云控制台、有监控但机器已经失去响应你要在最短时间内做出正确动作。下面按「先分类、再取证、后恢复」的顺序把每一步的命令、参数和踩过的坑讲清楚新手能照着敲熟手能对一下自己的应急手册有没有漏项。2. 先分清 Linux 死机的四种类型别把 IO hang 当内核 panic 处理Linux 死机不是一个单一状态处理方式完全取决于它卡在哪一层。我一般把它分成四类用户态卡死系统还在跑只是某个服务无响应、内核 panic内核自己崩了、IO hang磁盘或网络存储不返回、以及硬件级死机CPU、内存、主板出问题。分错类型后面的取证动作全是白费。2.1 从控制台和指示灯做第一轮判断如果你能碰到物理机或云厂商的 VNC 控制台先看三件事屏幕有没有输出、键盘 Caps Lock 灯能不能切换、机器风扇和硬盘灯的状态。Caps Lock 灯能切换说明内核还在调度中断大概率是用户态或部分 IO 卡死灯完全没反应基本是内核 panic 或硬件死机。云主机没有物理灯就看控制台的「重启」「强制关机」按钮是否还能响应以及云监控里 CPU、内存曲线是断崖还是持续高位。# 如果你还能通过带外管理IPMI/iDRAC/云控制台进入先看内核日志缓冲区 dmesg -T | tail -n 100 # -T 把内核时间戳转成可读时间tail 看最后 100 行panic 前一般会有 Oops 或 BUG 字样 # 看上一次启动到现在有没有硬件报错 journalctl -k -b -1 -p err # -k 只看内核消息-b -1 看上一次启动-p err 只看 error 及以上级别这两条命令的前提是系统还能响应。如果 SSH 已经断了就要靠串口 console 或者 kdump 留下的 vmcore 文件。参数上dmesg -T的时间戳依赖系统时钟如果死机前时钟被 NTP 跳变过时间会对不上这点在跨时区机房里要特别注意。2.2 用 Magic SysRq 在不重启的前提下抓现场Linux 内核内置了一组 Magic SysRq 组合键通过/proc/sys/kernel/sysrq控制。它的价值在于即使系统已经卡到无法登录只要内核还能响应键盘中断你就能强制同步磁盘、导出进程状态、甚至安全重启。常见做法是在物理机键盘上按Alt SysRq 字母云主机则通过串口发送对应字符。# 先确认 sysrq 功能是否开启1 表示全部开启 cat /proc/sys/kernel/sysrq # 临时开启全部功能重启后失效 echo 1 /proc/sys/kernel/sysrq # 常用组合物理键盘 AltSysRq字母串口发对应字符 # m - 导出内存信息到控制台 # t - 导出当前所有进程状态 # w - 导出不可中断D 状态进程 # s - 同步所有挂载的文件系统 # u - 重新以只读方式挂载 # b - 立即重启这里的关键是顺序s同步、u只读挂载、b重启也就是常说的s-u-b。直接按b会丢数据先s再u能把文件系统损坏概率降到最低。m和t是取证用的输出会打到当前控制台如果控制台没接串口日志这些信息就丢了所以生产机器一定要配串口重定向或 kdump。2.3 判断是不是 IO hangD 状态进程是核心线索IO hang 最迷惑人因为 CPU 可能很闲、内存也正常但所有涉及磁盘的操作全部卡住。典型现象是df卡住、ls卡住、ps里一堆进程处于D不可中断睡眠状态。这时候重启往往也重启不了因为关机流程要卸载文件系统一样会卡在 IO 上。# 统计 D 状态进程数量超过 5 个就要警惕 ps -eo state,pid,comm | awk $1D # 看这些进程卡在哪个内核调用上 cat /proc/PID/stack # 输出会显示内核栈如果停在 io_schedule、blk_mq 之类基本确认是块设备 IO hang # 看块设备队列和 IO 统计 iostat -x 1 5 # -x 显示扩展统计1 5 表示每秒采样一次共 5 次%util 接近 100 且 await 极高就是 IO 瓶颈/proc/PID/stack需要 root 权限且部分内核配置下普通进程看不到。如果输出是空的说明该进程不在内核态或者内核没开CONFIG_STACKTRACE。这时候退一步看iostat和dmesg里有没有blocked for more than 120 seconds这类告警那是内核 hung task 检测器在报 IO 卡死。3. 死机现场取证kdump、vmcore 和日志三件套怎么配死机处理最怕「重启完什么都没留下」。要能事后分析必须在机器还活着的时候就把 kdump 配好。kdump 的原理是内核 panic 时用一块预留内存启动一个「捕获内核」把崩溃内核的完整内存镜像vmcore写到磁盘或网络。没有它你只能靠串口日志里那几行 Oops。3.1 配置 kdump 并验证 vmcore 能落盘不同发行版配置方式略有差异但核心是给捕获内核预留内存、指定 vmcore 输出路径。以常见的 systemd 系发行版为例# 安装 kexec-toolskdump 依赖它加载捕获内核 yum install -y kexec-tools # RHEL/CentOS 系 apt install -y kdump-tools # Debian/Ubuntu 系 # 预留内存编辑 grub 配置在 crashkernel 参数里指定大小 # 一般 128M 起步内存大的机器给 512M 更稳 grep crashkernel /proc/cmdline # 启动 kdump 服务 systemctl enable --now kdump systemctl status kdump # 验证手动触发一次内核崩溃生产环境慎用 echo c /proc/sysrq-trigger # 机器会 panic 并重启重启后检查 /var/crash 下有没有 vmcore ls -lh /var/crash/crashkernelauto在新内核里能自动算预留大小但老内核上经常算得太小导致捕获内核起不来。我一般直接写死crashkernel512M宁可浪费一点内存。echo c /proc/sysrq-trigger是强制触发 panic只能在测试机做线上做之前确认业务已切走。3.2 用 crash 工具读 vmcore 定位崩溃点拿到 vmcore 后用crash工具配合对应版本的内核调试符号vmlinux分析。调试符号要和崩溃内核版本严格一致否则解析会错位。# 安装 crash 和内核调试符号 yum install -y crash kernel-debuginfo-$(uname -r) # 进入 crash 交互界面 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/vmcore # 常用命令 # bt - 查看崩溃时的调用栈 # log - 查看内核日志缓冲区 # ps - 查看崩溃瞬间的进程列表 # files - 查看打开的文件 # kmem -i - 查看内存使用概况bt是最关键的一条它会打印崩溃时的函数调用链。如果栈顶是panic、oops、BUG往下看是谁调用的。常见的是驱动 bug、内存越界、空指针。log能看到 panic 前最后的内核输出比串口日志更完整因为串口可能丢字符。3.3 日志三件套journalctl、dmesg、sar 的取数顺序不是每次死机都有 vmcore很多时候只能靠日志。取数顺序我一般是这样先journalctl -b -1看上次启动的完整日志再dmesg看内核环形缓冲区最后sar看死机前的资源曲线。# 看上一次启动的全部日志按时间倒序 journalctl -b -1 --no-pager | tail -n 500 # 只看内核相关的 error journalctl -k -b -1 -p err --no-pager # 看死机前的 CPU、内存、IO 历史需提前装 sysstat sar -u -f /var/log/sa/sa15 # 15 号那天的 CPU sar -r -f /var/log/sa/sa15 # 内存 sar -b -f /var/log/sa/sa15 # IOjournalctl -b -1依赖 journal 持久化配置如果/var/log/journal没建日志只存在内存里重启就没了。sar依赖sysstat服务默认可能没开生产机器建议提前启用并保留至少 7 天数据。这三样凑齐基本能还原死机前几分钟发生了什么。4. 避坑与排查死机处理里最容易翻车的五个动作这一章是我自己踩过和看别人踩过的坑每条按「现象 → 原因 → 解决」写照着对一遍能省不少后悔药。4.1 现象重启后 vmcore 没生成/var/crash 是空的原因通常是三种crashkernel预留内存太小捕获内核起不来/var/crash所在分区空间不够写不下或者 kdump 服务根本没设成开机自启panic 时没人接。解决先systemctl status kdump确认服务状态再grep crashkernel /proc/cmdline看预留大小最后df -h /var/crash看空间。三个都正常还不行就看/var/log/kdump.log里面会写捕获内核启动失败的具体原因。4.2 现象Magic SysRq 按了没反应原因一般是/proc/sys/kernel/sysrq被设成了 0或者云主机串口没开 SysRq 透传。有些发行版默认只开部分功能比如值 176b能用但t不能用。解决先cat /proc/sys/kernel/sysrq确认值需要全部功能就echo 1。云主机要在控制台的串口设置里确认「发送 SysRq」选项已开否则你发的字符到不了内核。4.3 现象IO hang 时执行 reboot 卡住机器既不死也不活原因是关机流程要卸载文件系统而文件系统正卡在 IO 上umount永远等不到返回。解决不要用reboot用echo b /proc/sysrq-trigger强制立即重启跳过所有卸载流程。代价是可能丢未落盘数据、文件系统需要 fsck但比一直卡着强。如果连 SysRq 都没反应只能带外强制断电这是最后手段。4.4 现象dmesg 里全是「blocked for more than 120 seconds」但不知道谁卡的原因是内核 hung task 检测器只报「有任务卡了 120 秒」不直接说是哪个设备。解决结合ps -eo state,pid,comm | awk $1D找到 D 状态进程再cat /proc/PID/stack看内核栈。如果栈里出现blk_mq、scsi、nfs等字样就能定位到具体是本地盘、SAN 还是网络存储。NFS 卡死尤其常见mount时加soft,timeo30能避免无限等待。4.5 现象内存看着没满但系统突然卡死日志里有 OOM原因是 OOM killer 触发时可能杀错了进程或者内存碎片导致分配失败但free显示还有余量。解决看journalctl -k | grep -i oom确认有没有 OOM 记录再看/proc/meminfo里的MemAvailable而不是MemFree。MemFree低不代表不够用MemAvailable才是真实可用。如果确认是 OOM调vm.overcommit_memory和vm.panic_on_oom要谨慎前者设 2 会让分配更严格后者设 1 会让 OOM 直接 panic 触发 kdump适合需要抓现场的机器。5. 把死机处理变成可复现流程串口日志、监控联动和一次演练前面讲的都是单点动作真正让死机处理不慌的是把它变成一套可复现的流程。我的习惯是每台生产机器上线前串口日志重定向、kdump、sysstat 三样必须配好缺一样都不让进池子。串口日志的价值在于内核 panic 时哪怕 kdump 没起来串口也能把 Oops 那几行打出来这是最后的黑匣子。# 配置串口日志重定向到文件以 GRUB 为例 # 编辑 /etc/default/grub在 GRUB_CMDLINE_LINUX 里加 # consoletty0 consolettyS0,115200n8 # 然后更新 grub 并重启 grub2-mkconfig -o /boot/grub2/grub.cfg # Debian/Ubuntu 用 update-grub # 用 screen 或 minicom 接串口把输出落盘 screen -L -Logfile /var/log/serial-$(date %F).log /dev/ttyS0 115200 # -L 开启日志-Logfile 指定路径/dev/ttyS0 是串口设备115200 是波特率参数上consoletty0 consolettyS0,115200n8里的n8是无校验、8 数据位这是串口标准配置改错会乱码。screen -L的日志文件要定期轮转否则会撑满磁盘。云主机一般用厂商提供的串口日志功能不用自己接 screen但要在控制台里确认「串口日志」已开启并设置了保留时长。监控联动这块我一般会在监控系统里加两条规则一是node_load1超过核数 3 倍且持续 5 分钟告警二是node_procs_blockedD 状态进程数大于 5 告警。这两条能在系统彻底死透之前给出预警留出取证时间。告警触发后自动化脚本可以先抓一份dmesg、ps、iostat快照存到远端再通知人介入。最后说演练。kdump 配了不代表能用我见过太多「配了但 panic 时没生成 vmcore」的案例。建议每季度在测试机做一次echo c /proc/sysrq-trigger确认 vmcore 能落盘、crash 能解析、串口日志有输出。演练时把整个流程走一遍触发 panic → 等重启 → 检查/var/crash→ 用 crash 读bt→ 确认能定位到触发点。走通了真出事时才不会手忙脚乱。我自己就吃过亏一台机器配了 kdump 但从没验证过真 panic 时发现crashkernel预留太小捕获内核根本没起来白白丢了一次现场。从那以后验证 kdump 成了我上线检查清单里的固定项。希望帮到你。本文还有配套的精品资源点击获取