简介：面向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. 如果系统用 systemd，journalctl 里的内核日志更全，带时间戳更好对齐 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 error"soft lockup 的意思是某个 CPU 核上的内核线程卡了 20 秒以上没让出执行权，通常是驱动死循环、文件系统代码 bug 或者内核模块互相等待；hung_task 是用户态进程阻塞超过 120 秒（默认值），blocked for more than 120 seconds 这句话出现时，先查存储。OOM 那行会直接告诉你哪个进程吃光了内存、内核杀了谁，很多“假死机”其实就是内存被某个进程吃到只剩几十 MB，系统所有操作都在等内存回收，看起来像死机，其实还活着。
MCE（Machine 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
系统彻底不响应时，键盘组合键 Alt+SysRq+字母 是唯一还能和内核对话的通道。字母决定了内核执行什么操作，顺序极其重要，乱按等于瞎折腾。我的固定序列是这几个字母，按时间间隔 2-3 秒逐个发送：
# 按顺序执行：等待 2-3 秒再按下一个 Alt+SysRq+R # 恢复键盘原始模式，把被 X 图形栈劫持的键盘控制权夺回来 Alt+SysRq+S # 同步所有已挂载文件系统，把缓存里的数据刷到磁盘 Alt+SysRq+E # 给所有进程发送 SIGTERM，优雅终止 # 等待 10 秒，给进程留出收尾清理时间 Alt+SysRq+U # 重新挂载所有文件系统为只读，防止后续写入损坏 Alt+SysRq+B # 立即重启系统这个序列的逻辑是：先恢复键盘控制，再做一次数据落盘，再通知进程退出，然后把文件系统切到只读，最后才重启。每一步都在降低强制重启的数据损坏概率。有人会跳过 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\|segfault"fsck 的 -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 输出的信息比较硬核，但判断逻辑不复杂：CE（Corrected Error）是可纠正错误，偶尔一次不用管，但数量持续增长说明硬件在劣化；UE（Uncorrected 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_cstate=1 processor.max_cstate=1"这个参数的意思是让 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 组合键没有任何反应
排查死机时按了 Alt+SysRq+B，系统纹丝不动，以为是内核彻底死了，最后发现是 /proc/sys/kernel/sysrq 的值是 0，魔术键功能被默认关闭。很多云主机镜像和国产 Linux 发行版默认就是关的，而且不会在任何文档里告诉你。
解决：提前在所有机器上部署 sysctl 配置，把 kernel.sysrq 设为 1。另外注意笔记本上 SysRq 键需要和 Fn 组合才能触发，比如 ThinkPad 上是 Alt+Fn+PrintScreen+字母，直接按 Alt+PrintScreen 会发现毫无反应。
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，系统开始疯狂 swap，ssh 敲个命令都要 30 秒才回显，远程操作基本没法进行。同事判断是死机，准备强制重启，但实际系统还活着，只是内存回收导致全程卡顿。
解决：这种情况下不要重启，重启反而让问题更严重。先等 OOM killer 把进程杀掉，再用短时间窗口的操作释放内存：echo 3 > /proc/sys/vm/drop_caches 清理页缓存，或者直接 kill 掉内存占用最大的进程而不是重启整个系统。根本上限制 swap 使用策略，把 vm.swappiness 调低到 10 左右。
5.5 现象：强制重启后日志全部丢失
使用 Ctrl+Alt+Del 或 SysRq 重启后，登录系统想看死机前日志，发现 /var/log/messages 里干干净净，一点记录都没有。原因是日志守护进程在死机前也卡死了，日志根本没刷盘，或者 journald 在强制重启后把旧日志标记为不可读。
解决：重要机器上把 journald 的 Storage 改成 persistent，并设置 SystemMaxUse 控制日志上限，确保日志落盘到持久化目录而非内存盘：
# /etc/systemd/journald.conf Storage=persistent SystemMaxUse=2G然后重启 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 2>&1; 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 服务里，开机自启一次，结果写到日志文件。从那以后，每次死机重启后我都会先看这个脚本的输出，确认根因之前先排除“文件系统损伤、转储未保留、磁盘劣化”这三个最容易犯的低级错误。这套流程我强制自己走了大半年，踩坑记录里的五条问题基本再没犯过，希望帮到你。
本文还有配套的精品资源，点击获取
