简介面向Linux运维与故障排查人员的一份技术资料聚焦系统死机或崩溃后如何有效收集与分析转储信息。资料系统梳理了三种典型机制Core dump用于捕获应用程序异常崩溃时的内存现场Diskdump无需网络即可在单机保留分区保存内核转储Netdump则适合不支持Diskdump的环境将崩溃信息发送至远程服务器分析。三类方法覆盖应用层与内核层故障可帮助判断问题是硬件故障还是应用程序bug所致。资源为单个doc文档共1个文件压缩包大小仅47KB便于下载后直接查阅或打印。目前已有528人学习使用适合具备一定Linux基础、希望掌握崩溃诊断思路的运维工程师参考。文档内容包含具体命令配置、HP SCSI设备下的diskdump启用步骤、netdump服务器与客户端配置示例以及网卡netpoll支持性判断说明均为实践中可直接落地的排错要点。1. Linux 死机处理方法先分清“真死”还是“假死”接手过不少“死机”工单十次里有六次不是真死机SSH 连不上、屏幕冻住、鼠标还能动但点什么都没反应现象五花八门根因却可能差着十万八千里。Linux 死机处理方法本质上不是一套“按哪个键重启”的万能流程而是一套从现象反推故障层、再决定介入手段的排查方法。这篇我把软死机、硬死机、内核 panic、硬件故障这几类都拆开讲落到 sysrq 魔术键、日志取证、看门狗、kdump 这些能直接上手的配置上。适合给线上 Linux 做运维、或者在自己开发机上折腾系统的人花十几分钟看完下次遇到死机至少知道第一步该敲什么、什么情况绝对不能直接断电。2. 死机现场分级从现象反推故障层与取证命令2.1 三种“死机”表象冻屏、黑屏、远程失联死机这个说法太笼统真要排查得先把手头看到的表象分个类。我一般按“还能不能响应”来分三档。第一档是冻屏最常见。屏幕画面卡住鼠标能动但点击无响应或者连鼠标都一起卡住。这种大概率是图形栈、GPU 驱动或者某进程把 CPU 占满后把系统拖垮了也可能是内核线程死锁。第二档是黑屏显示器直接无信号但主机电源灯还亮着远程 SSH 可能还能连上。这种情况优先怀疑显卡驱动崩溃、显存故障或者系统进入了某种休眠/待机异常状态。第三档是远程失联服务器 ping 不通、SSH 连不上BMC/IPMI 里看机器还开着但系统完全不响应了。这一档最危险因为拿不到屏幕信息只能靠串口、日志或者强制重启来恢复。先说个结论不管是哪一档千万别一上来就拔电源。很多线上故障原本只是内核软锁拔一次电反而把文件系统搞出问题把“软件死机”硬生生升级成“硬件救援”。正确做法是先尝试从外部取证确认系统到底死在哪一层。2.2 第一现场取证dmesg、journalctl、top 与 uptime 的组合系统还没完全断气的时候第一现场取证靠几个命令就能完成。这套组合我在排查 Linux 运维故障案例时几乎是固定开局能救命的信息基本都在里面。# 1. 看系统负载与运行时长uptime 的 load average 三个值异常飙升时说明系统还在挣扎 uptime # 2. 看内存与进程状态重点看 D 状态不可中断睡眠进程 top -b -n 1 | head -50 # 3. 拉取内核环形缓冲区最近一圈日志死机前 10 分钟的系统喊话全在这里 dmesg -T | tail -200 # 4. 如果系统用 systemdjournalctl 里的内核日志更全带时间戳更好对齐 journalctl -k -b -n 200 --no-pager第一行 uptime 的输出里load average 三个数字分别代表 1 分钟、5 分钟、15 分钟的平均负载。如果 1 分钟值远大于 15 分钟值说明系统是刚刚才开始过载如果三个值都高且很接近说明已经持续高负载很久了。第二行 top 命令里我主要看 STAT 列出现大量 D 状态进程说明有进程卡在 IO 上大概率是存储或网络存储出了问题大量 R 状态进程说明 CPU 被打满可能是某个业务进程死循环。第三行 dmesg 是核心中的核心。内核在 panic、soft lockup、OOM、IO error 之前都会往这里写日志。注意 dmesg -T 是把时间戳转成人类可读格式不同发行版对 dmesg 的权限限制不一样有些环境需要 sudo。第四行 journalctl -k 专门看内核日志-b 表示当前这次启动如果你的系统已经重启过了想看上次启动的日志要加 -b -1这个参数后面排查时会反复用到。2.3 内核日志里的关键线索soft lockup、hung_task、OOM日志拉回来了怎么判断死机原因我习惯先 grep 几个高频关键词这几个词出现的位置基本就是故障点。# 检索软锁与硬锁出现则说明 CPU 上有内核线程卡死超过阈值 dmesg -T | grep -i soft lockup\|hard lockup # 检索任务卡死说明某个进程占着资源不放IO 栈嫌疑最大 dmesg -T | grep -i hung_task\|blocked for more than # 检索内存不足OOM killer 触发时系统会大批杀进程 dmesg -T | grep -i out of memory\|oom-killer # 检索硬件错误MCE 报错基本就是 CPU 或内存实体故障 dmesg -T | grep -i mce\|machine check\|hardware errorsoft lockup 的意思是某个 CPU 核上的内核线程卡了 20 秒以上没让出执行权通常是驱动死循环、文件系统代码 bug 或者内核模块互相等待hung_task 是用户态进程阻塞超过 120 秒默认值blocked for more than 120 seconds 这句话出现时先查存储。OOM 那行会直接告诉你哪个进程吃光了内存、内核杀了谁很多“假死机”其实就是内存被某个进程吃到只剩几十 MB系统所有操作都在等内存回收看起来像死机其实还活着。MCEMachine Check Exception是硬件层面最直接的证据一旦出现基本可以断定不是软件问题。这四条命令跑完故障层就能从“系统死机”收敛到“CPU 卡死 / IO 阻塞 / 内存耗尽 / 硬件故障”四个方向之一后面的处理手段完全不同。3. 软死机处理节奏SysRq 魔术键与降级重启的正确顺序3.1 开启 SysRq内核参数与 /proc/sys/kernel/sysrq确认是软死机系统不响应但电源灯亮、风扇转之后下一步不是重启而是尝试用 SysRq 魔术键做受控降级。SysRq 是 Linux 内核内置的一套紧急命令接口可以在系统快死的时候让内核执行一些受控操作比如同步磁盘、卸载文件系统、强制重启相当于给内核留了一扇后门。先确认这扇门开着没有# 查看当前 sysrq 开关值1全部开启0全部关闭 cat /proc/sys/kernel/sysrq # 临时开启全部 sysrq 功能重启后失效 echo 1 /proc/sys/kernel/sysrq # 永久开启写入 /etc/sysctl.d/99-sysrq.conf echo kernel.sysrq 1 /etc/sysctl.d/99-sysrq.conf sysctl -p /etc/sysctl.d/99-sysrq.conf/proc/sys/kernel/sysrq 这个开关的值有讲究。0 是完全关闭1 是开启全部功能大于 1 的数值是位掩码比如 2 只允许同步文件系统16 只允许重启。线上环境我一般建议直接设 1因为出故障时你不知道自己到底需要哪个功能全开比到时候发现某个操作被禁了强。这个设置在 Ubuntu、Debian、CentOS 和国产 Linux 发行版上路径都一样唯一区别是某些国产发行版的内核可能裁剪过 sysrq 的编译选项写了 sysctl 也不生效那只能下次换内核时注意。还有一层容易忽略如果你用的是云服务器键盘上的 SysRq 键根本不存在这时候要靠另一种方式触发后面会讲到。3.2 按序降级从 Sync 到 Unmount 再到 Reboot系统彻底不响应时键盘组合键 AltSysRq字母 是唯一还能和内核对话的通道。字母决定了内核执行什么操作顺序极其重要乱按等于瞎折腾。我的固定序列是这几个字母按时间间隔 2-3 秒逐个发送# 按顺序执行等待 2-3 秒再按下一个 AltSysRqR # 恢复键盘原始模式把被 X 图形栈劫持的键盘控制权夺回来 AltSysRqS # 同步所有已挂载文件系统把缓存里的数据刷到磁盘 AltSysRqE # 给所有进程发送 SIGTERM优雅终止 # 等待 10 秒给进程留出收尾清理时间 AltSysRqU # 重新挂载所有文件系统为只读防止后续写入损坏 AltSysRqB # 立即重启系统这个序列的逻辑是先恢复键盘控制再做一次数据落盘再通知进程退出然后把文件系统切到只读最后才重启。每一步都在降低强制重启的数据损坏概率。有人会跳过 SIGTERM 直接到 U但我建议不要省很多应用收到 SIGTERM 后能自己把配置文件和状态存好省掉你用 fsck 满世界找破损文件的时间。如果没有物理键盘服务器、云主机可以通过内核提供的另一个入口触发相同操作# 向 /proc/sysrq-trigger 写入字母等价于按键盘组合键 echo s /proc/sysrq-trigger # 同步文件系统 echo u /proc/sysrq-trigger # 重挂只读 echo b /proc/sysrq-trigger # 重启注意 echo 到 /proc/sysrq-trigger 的前提是系统还能执行命令也就是 SSH 还通或者你能在本地终端敲命令。这套写法在自动化脚本里很常用我们后面讲看门狗自愈时还会用到。还有个小细节往 /proc/sysrq-trigger 写入前同样要先确认 kernel.sysrq 是开着的不然操作会被内核直接忽略。单独强调一遍 REISUB 里的 U 操作。文件系统重挂为只读这一步是“后悔药”没有它强制重启后根文件系统可能直接变成只读不可进你得进救援模式跑 fsck有它至少磁盘上已经落盘的数据是干净的没来得及写的内容最多丢一点缓存不会破坏结构。3.3 强制重启后的善后fsck 与日志核对强制重启之后千万别急着把服务拉起来就算完事。系统十有八九会经历一次文件系统检查或直接拒绝启动这时候要从 grub 菜单进救援模式跑一遍文件系统修复。# 在救援模式或单用户模式下检查并修复根文件系统 fsck -f /dev/sda1 # 查看上次启动的内核日志确认死机根因 journalctl -k -b -1 -n 300 --no-pager # 查看前一次启动时是否有 OOM、panic 等关键事件 journalctl -b -1 --no-pager | grep -i panic\|out of memory\|segfaultfsck 的 -f 参数是强制检查即使文件系统标记为 clean 也会完整扫一遍。注意 fsck 不能在系统挂载根文件系统时直接跑所以一定要先进救援模式或使用 live CD。journalctl 的 -b -1 是查看上一次启动的日志这个参数在“重启后复盘”场景里价值极高很多运维习惯只盯着当前日志看结果线索都留在上一次启动的日志里翻个参数就能看到 panic 之前的完整上下文。善后这一步我还会做一件事用 smartctl 看磁盘健康状态。死机往往伴随非正常断电SSD 和机械盘都可能因此产生重映射扇区或坏道# 查看磁盘 SMART 信息重点关注 Reallocated_Sector_Ct 和 Current_Pending_Sector smartctl -a /dev/sda | grep -i reallocated\|pending\|error如果这两个值在死机前后有明显上涨说明磁盘已经扛不住了这次死机不是软件问题而是硬件告警该考虑换盘了。4. 硬件死机边界CPU、内存与存储的排查参数4.1 CPU 与内存MCE、EDAC、memtest86 的边界软件层面的死机排查完还查不出结果就要开始怀疑硬件。硬件死机和软件死机最大的区别在于软件死机重启后基本能恢复正常硬件死机则是“间歇性发作”可能一周没事然后又死一次而且死机时的报错五花八门很难复现。CPU 和内存故障的判断依据主要看 MCE 日志和 EDAC 报告。# 查看 MCE 硬件错误记录CPU 内部错误、缓存错误、内存控制器错误都会在这里 mcelog --client # 或使用 ras-mc-ctl 查看错误汇总新内核用 rasdaemon 替代 ras-mc-ctl --summary rasdaemon --status # EDAC 报告内存控制器错误有 CE可纠正和 UE不可纠正两种 find /sys/devices/system/edac -name *_count -exec sh -c echo $1: $(cat $1) _ {} \;mcelog 和 rasdaemon 输出的信息比较硬核但判断逻辑不复杂CECorrected Error是可纠正错误偶尔一次不用管但数量持续增长说明硬件在劣化UEUncorrected Error是不可纠正错误一旦出现十有八九系统已经死机或即将死机这块内存或 CPU 就该换了。我遇到过一台机器一个月内死机三次dmesg 干干净净最后是 rasdaemon 里累计了几百条 CE 记录而主菜单栏没有任何提示定位到内存条后才消停。软件层面还有一个工具值得跑一遍memtest86。这个需要在系统启动时从 U 盘引导跑完整一轮要几十个小时不适合线上紧急处理但适合离线彻底排查。跑的时候建议先只插一根内存条测完再换另一根不然 MEMTEST 报错了你也分不清是哪根的问题。如果是嵌入式 Linux 项目或者工控机场景没有标准内存槽也没法跑 memtest那就只能靠内核日志里的 EDAC 和硬件 watchdog 报错来推断。这类设备死机问题处理起来更麻烦因为很多嵌入式 SoC 根本没有完整的 MCE 上报机制日志里可能只有一个 reset 原因寄存器记录需要在 bootloader 阶段抓。4.2 存储卡死IO hang 与 soft lockup 的区分存储导致的死机是运维场景里的重灾区也是判断起来最玄学的一类。SSD 掉固件、磁盘坏道、RAID 卡缓存策略异常、NFS 远程存储断连最终表现可能都是同一个字——卡。但细分下来有两个明显特征可以帮助区分。第一个特征是 IO hang表现为 D 状态进程堆积system load 持续上升但 CPU 使用率很低。这种场景在 dmesg 里通常有 hung_task timeout 或 block 相关的报错# 查看 D 状态进程与对应内核栈 cat /proc/进程PID/stack # 查看 IO 队列深度数值异常高说明存储后端已经堵死 cat /sys/block/sda/queue/iodepth iostat -x 1看到 %util 持续 100% 但 w_svctm 异常高时优先怀疑存储后端。如果你的系统跑在虚拟机上还要检查宿主机层面的存储性能是不是被邻居“吵”到了虚拟机里看到的 IO 延迟往往会掩盖宿主机上的真实瓶颈。第二个特征是 soft lockup存储驱动或文件系统代码里出现死循环或不可中断的等待导致 CPU 核被锁住。这种时候 dmesg 里能看到明显的 soft lockup 字样还会带着一个内核栈回溯栈回溯里出现的函数名基本就能定位到是哪个驱动出了问题。NVIDIA GPU 驱动导致的内核线程死循环、某些国产 SSD 厂商的私有 NVMe 驱动实现有 bug都是这类问题的常客。4.3 固件层面的坑C-State、电源策略与 BMC硬件排查到了最后一步往往是固件设置背锅。很多服务器死机不是硬件真坏了而是 BIOS 的电源管理策略和 Linux 内核调度器冲突。C-State 是 CPU 的空闲电源状态C6 甚至更深的 C10 状态下CPU 核会完全关闭时钟唤醒延迟变大。如果内核、BIOS、虚拟机管理器对 C-State 的预期不一致就可能出现“CPU 唤不醒”的假死机现象。处理方式是在内核启动参数里关掉深 C-State# /etc/default/grub 中追加内核参数然后 update-grub / grub2-mkconfig GRUB_CMDLINE_LINUX... intel_idle.max_cstate1 processor.max_cstate1这个参数的意思是让 CPU 最多只能进入 C1 状态虽然功耗会高一些但能换来系统稳定性对线上数据库和虚拟化宿主机尤其重要。还有一部分死机是 BMC/BIOS 的看门狗和系统超时设置不匹配导致的系统启动过程中固件里的 watchdog 先启动了Linux 内核还没加载对应驱动超时后 BMC 直接帮你重启。这种“死机”你连日志都看不到因为系统根本没跑到记录日志那一步只能通过 BMC 的事件日志SEL/System Event Log查看。5. 死机处理避坑指南五条高频翻车记录5.1 现象拔电重启后根文件系统损坏无法挂载一次线上数据库服务器死机现场同事直接断电重启结果系统卡在 emergency mode根文件系统报错无法挂载。原因是断电前有大量缓存数据没落盘日志文件系统崩溃后需要 replay但断电中断了 replay 过程。解决不要直接拔电先试 SysRq 的 S同步和 U只读重挂。如果已经断电导致无法挂载从救援模式进系统跑 xfs_repair -L 或 fsck.ext4 -fy注意 -L 会清空日志是最后手段跑之前一定要确认没有更早的备份。5.2 现象SysRq 组合键没有任何反应排查死机时按了 AltSysRqB系统纹丝不动以为是内核彻底死了最后发现是 /proc/sys/kernel/sysrq 的值是 0魔术键功能被默认关闭。很多云主机镜像和国产 Linux 发行版默认就是关的而且不会在任何文档里告诉你。解决提前在所有机器上部署 sysctl 配置把 kernel.sysrq 设为 1。另外注意笔记本上 SysRq 键需要和 Fn 组合才能触发比如 ThinkPad 上是 AltFnPrintScreen字母直接按 AltPrintScreen 会发现毫无反应。5.3 现象显卡驱动更新后偶发冻屏一台 Ubuntu 工作站频繁冻屏每次都是图形界面卡死重装系统后问题依旧怀疑是显卡硬件故障。后来发现是用户用 -ui 参数直接从 NVIDIA 官网装了驱动和内核自带的 nouveau 模块冲突两个驱动在内核里同时加载互相打架。解决彻底卸载 nouveau用发行版仓库里的 nvidia-driver 包安装或者使用官方 runfile 安装时加 --no-opengl-files。装完检查 /proc/driver/nvidia/version 确认驱动生效并在 /etc/modprobe.d/ 里 blacklist nouveau让两个驱动永远不同时出现。5.4 现象OOM killer 杀进程后系统像死机一样卡顿一个 Java 应用服务物理内存 64G配置了 -Xmx48G实际使用超过 60G 时触发 OOM系统开始疯狂 swapssh 敲个命令都要 30 秒才回显远程操作基本没法进行。同事判断是死机准备强制重启但实际系统还活着只是内存回收导致全程卡顿。解决这种情况下不要重启重启反而让问题更严重。先等 OOM killer 把进程杀掉再用短时间窗口的操作释放内存echo 3 /proc/sys/vm/drop_caches 清理页缓存或者直接 kill 掉内存占用最大的进程而不是重启整个系统。根本上限制 swap 使用策略把 vm.swappiness 调低到 10 左右。5.5 现象强制重启后日志全部丢失使用 CtrlAltDel 或 SysRq 重启后登录系统想看死机前日志发现 /var/log/messages 里干干净净一点记录都没有。原因是日志守护进程在死机前也卡死了日志根本没刷盘或者 journald 在强制重启后把旧日志标记为不可读。解决重要机器上把 journald 的 Storage 改成 persistent并设置 SystemMaxUse 控制日志上限确保日志落盘到持久化目录而非内存盘# /etc/systemd/journald.conf Storagepersistent SystemMaxUse2G然后重启 journald 服务。还有一个习惯遇到死机不要急着重启先尝试通过串口或 BMC 的 SOL 控制台抓取屏幕输出很多关键报错就在屏幕上但一重启就没了。6. 让死机可预期kdump 现场保留与看门狗自愈配置6.1 kdump 配置与验证给内核留一份“遗书”死机最怕什么不是死本身而是死了之后不知道是怎么死的。kdump 机制能在内核 panic 的瞬间把内存里的现场转储出来分析 crash dump 能精确定位到是哪一行代码导致崩溃。部署也不算麻烦# 安装 kdump 工具Debian/Ubuntu 示例CentOS 用 kexec-tools apt install linux-crashdump # 安装时自动配置崩溃预留内存 # 确认 crashkernel 参数已生效重启后检查 cat /proc/cmdline | grep crashkernel # 查看 kdump 服务状态 systemctl status kdump-tools验证 kdump 是否能正常工作可以主动注入一次 panic# 注意这条命令会立刻触发系统崩溃并重启只能在测试机上执行 echo c /proc/sysrq-trigger重启后检查 /var/crash 目录下是否生成了 vmcore 文件。有这个文件下一次死机你就不再是两眼一抹黑可以用 crash 或 gdb 打开 vmcore 分析崩溃现场。这不是锦上添花而是把死机处理从“靠经验猜”变成“靠证据查”的分水岭。6.2 watchdog 与自动化自愈脚本没人盯着也能自己活过来线上服务器没人 24 小时盯着死机了不能总靠人工救援得让系统自己恢复。软件看门狗是最省事的方案# 安装 watchdog 并启用 apt install watchdog echo watchdog-device /dev/watchdog /etc/watchdog.conf systemctl enable --now watchdog # 配置内核软看门狗软狗超时后触发系统重启 echo softdog /etc/modules-load.d/softdog.conf modprobe softdog更可靠的做法是在硬件 watchdog 上做双重保险服务器主板自带的 BMC watchdog 即使系统内核完全死掉也会在超时后自动重启。配置方式是通过 ipmitool 设置 BMC 看门狗超时时间# 设置 BMC watchdog超时 300 秒后自动复位系统 ipmitool mc watchdog set 300这套“内核看门狗 BMC 看门狗”的双层配置能覆盖大部分死机场景用户态卡死时软狗超时重启内核死锁时硬件狗兜底BMC 本身由独立电源供电即使系统电源管理异常它也能执行复位。6.3 死机后的自动化复盘脚本把恢复动作标准化我从一次凌晨三点爬起来修服务器的经历里学到一个教训死机处理流程再熟练人不在现场也没用而人在现场时往往还带着困意记不住步骤。所以后来我把恢复动作写成了一个脚本死机重启后自动执行一次健康检查#!/bin/bash # /usr/local/bin/post-crash-check.sh # 1. 检查根文件系统是否以只读方式挂载是则重新挂载为读写 if grep -q / .*ro, /proc/mounts; then mount -o remount,rw / echo [CHECK] rootfs remounted rw fi # 2. 检查崩溃转储是否生成有则打包留档 if ls /var/crash/vmcore* /dev/null 21; then tar czf /var/crash/$(date %F-%H%M)-vmcore.tar.gz /var/crash/vmcore* echo [CHECK] vmcore archived fi # 3. 比对磁盘 SMART 健康值变化 smartctl -a /dev/sda | grep -E Reallocated_Sector_Ct|Current_Pending_Sector \ /tmp/smart-before diff /tmp/smart-before /var/log/smart-last 2/dev/null || echo [WARN] SMART changed脚本逻辑不复杂关键是把它放进 systemd 的 oneshot 服务里开机自启一次结果写到日志文件。从那以后每次死机重启后我都会先看这个脚本的输出确认根因之前先排除“文件系统损伤、转储未保留、磁盘劣化”这三个最容易犯的低级错误。这套流程我强制自己走了大半年踩坑记录里的五条问题基本再没犯过希望帮到你。本文还有配套的精品资源点击获取