简介这是一份面向Linux运维工程师与系统管理员的故障排查参考资料聚焦系统死机或崩溃后如何有效采集与分析现场信息帮助判断问题源于硬件故障还是应用程序缺陷。资源以doc文档形式交付压缩包内共1个文件体积约47KB内容围绕Core dump、Diskdump与Netdump三种崩溃信息获取机制展开涵盖核心转储的启用与保存路径配置、单机内核转储分区的初始化流程以及通过远程服务器接收vmcore的部署方式。文档对每种方法的适用场景、配置要点与注意事项均有说明例如core文件命名格式、diskdump保留分区设置、netdump服务端与客户端的参数填写等便于读者按图索骥搭建调试环境。目前已有527人学习适合需要提升系统稳定性与故障定位效率的运维人员参考可在崩溃发生后快速获取关键内存与内核状态信息缩短排障周期。1. 线上 Linux 死机了先别急着重启一套能救回现场的处理思路凌晨两点被告警叫醒SSH 连不上、ping 不通、业务全挂第一反应往往是「重启算了」。但重启之后现场全没了下次同样的死机还会再来一遍。Linux 死机处理真正难的不是「让它活过来」而是在重启之前把现场证据留下来搞清楚是内核 panic、OOM、IO hang 还是硬件故障。这套方法适合所有跑着生产业务的运维和开发从刚接手服务器的新手到需要定位疑难杂症的老手。下面按「先取证、再判断、后恢复」的顺序把每一步的命令、参数和坑讲清楚让你下次遇到死机不再靠玄学。2. 死机现场取证从控制台到内核日志的完整链路死机处理的第一原则是能取证就别重启。Linux 死机大致分几类内核 panic屏幕打印一堆调用栈后彻底不动、OOM Killer 触发内存耗尽杀进程严重时系统卡死、IO hang磁盘或存储链路卡住进程进入 D 状态、硬件故障内存、CPU、电源。不同类型的取证入口不一样但顺序基本一致先看能不能进控制台再看内核日志最后看进程和资源状态。2.1 判断死机类型SSH 不通不等于系统死了很多人一发现 SSH 连不上就判定「死机」其实可能只是 sshd 挂了、网络断了或者防火墙拦了。先做分层判断别一上来就重启。# 从另一台机器测试网络层是否还活着 ping -c 4 192.168.1.100 # 测试 SSH 端口是否开放22 换成你的实际端口 nc -zv 192.168.1.100 22 # 如果配了带外管理IPMI/iDRAC/iLO直接看控制台画面 # 云服务器则看 VNC 控制台逻辑说明ping通但nc不通说明网络层活着、sshd 可能挂了这时候系统大概率没死可以尝试通过带外控制台登录。ping都不通才可能是内核级死机。参数上-c 4是发 4 个包就停避免一直刷屏nc -zv的-z是只探测端口不传数据-v输出详细信息。如果带外控制台能看到画面重点看两样东西屏幕上有没有Kernel panic、BUG:、Call Trace这类字样以及能不能敲键盘响应。键盘有响应说明只是某个服务或网络挂了键盘完全无响应才是真死机。2.2 用 SysRq 抢救内核日志死机前最后的后悔药Linux 内核有个「魔术键」SysRq即使系统看起来完全卡死只要内核没彻底崩溃它还能响应。这是死机取证里最值钱的一招血泪经验是很多人不知道它重启后什么线索都没了。# 前提内核参数 kernel.sysrq 需要开启值为 1 或 438 等 cat /proc/sys/kernel/sysrq # 临时开启重启失效 echo 1 /proc/sys/kernel/sysrq # 死机时依次按物理键盘 AltSysRq对应键串口/控制台用 echo 写 # 让内核尽量同步数据到磁盘减少文件系统损坏 echo s /proc/sysrq-trigger # 导出当前所有进程的调用栈到 dmesg看谁卡住了 echo t /proc/sysrq-trigger # 导出所有 CPU 的寄存器信息 echo l /proc/sysrq-trigger # 导出内存信息 echo m /proc/sysrq-trigger # 最后安全重启 echo b /proc/sysrq-trigger逻辑说明s是 sync把脏页刷盘t是导出任务状态能看出哪些进程处于 D 状态不可中断睡眠通常是 IO 卡住l导出 CPU 寄存器m导出内存b是立即重启。顺序很重要——先s再t/l/m最后才b这样重启前日志已经落到磁盘。参数上/proc/sysrq-trigger是内核提供的触发接口写什么字符就执行什么动作。注意echo b是不卸载文件系统直接重启有丢数据风险只在确认系统已经无法正常关机时用。生产环境建议提前把kernel.sysrq设为 1并配置 kdump别等死机了才想起来。2.3 从 dmesg 和 journal 里捞出关键证据如果系统还能进哪怕只是短暂恢复第一件事是把内核环形缓冲区和系统日志导出来。dmesg 记录的是内核态信息OOM、IO 错误、硬件报错都在里面。# 导出完整内核日志带时间戳 dmesg -T /tmp/dmesg_$(date %F_%H%M).log # 只看错误和警告级别 dmesg -T --levelerr,warn # 用 journalctl 看本次启动的日志-k 只看内核 journalctl -k -b -0 --no-pager /tmp/journal_kernel.log # 看上一次启动的日志如果已经重启过这是找回现场的关键 journalctl -k -b -1 --no-pager逻辑说明dmesg -T把内核时间戳转成可读时间方便和业务日志对齐--levelerr,warn过滤级别避免被海量信息淹没journalctl -k只看内核消息-b -0是本次启动-b -1是上一次启动。参数--no-pager防止输出被分页器截断方便重定向到文件。重点搜几个关键词Out of memoryOOM、blocked for more thanIO hang、I/O error磁盘故障、Kernel panic、Hardware Error、MCE机器检查异常通常是内存或 CPU 硬件问题。这些词直接指向死机根因。2.4 进程与资源快照D 状态进程是 IO hang 的铁证如果系统还能响应命令赶紧抓一份进程和资源快照。D 状态不可中断睡眠进程扎堆基本就是 IO 或存储链路出问题了。# 抓所有 D 状态进程 ps -eo pid,ppid,stat,wchan:32,cmd | awk $3 ~ /D/ # 看谁在占内存按 RSS 排序 ps -eo pid,comm,rss --sort-rss | head -20 # 看负载和 IO 等待 uptime vmstat 1 5 # 看内存和 swap 使用 free -h逻辑说明ps的stat列里D就是不可中断睡眠wchan显示进程卡在哪个内核函数是定位 IO hang 的关键--sort-rss按物理内存倒序快速找出内存大户vmstat 1 5每秒采样一次共 5 次重点看waIO 等待和si/soswap 换入换出wa长期很高说明磁盘是瓶颈。注意D 状态进程用kill -9是杀不掉的因为它不响应信号。这时候别反复 kill没用要去看它卡在哪个设备上。3. 常见死机场景的定位与恢复OOM、IO hang、内核 panic取证做完接下来是对号入座。不同死机场景的处理手法差别很大用错方法可能把可恢复的问题搞成必须重启。3.1 OOM 导致卡死先看是谁吃光了内存OOM 是最常见的「软死机」。内核内存耗尽时会触发 OOM Killer 杀进程但如果杀的都是小进程、或者内存碎片严重系统会长时间卡在回收内存上表现为负载极高、命令响应极慢。# 确认是否发生过 OOM dmesg -T | grep -i out of memory journalctl -k | grep -i oom # 看 OOM 杀了谁以及当时的内存分布 grep -i oom /var/log/messages # 调整 OOM 行为让关键进程不被杀值越小越不容易被杀 echo -1000 /proc/关键进程PID/oom_score_adj # 临时禁用某个 cgroup 的 OOM Killer谨慎 # 生产更推荐用 systemd 的 MemoryMax 限制逻辑说明oom_score_adj范围是 -1000 到 1000-1000 表示几乎不会被 OOM 杀1000 表示优先被杀。给数据库、核心网关设负值能保命。但根治办法是限制内存用 systemd 的MemoryMax或 cgroup v2 给每个服务设上限别让一个服务拖垮整机。# systemd 服务限制内存的写法放到 service 的 [Service] 段 # MemoryMax2G # MemoryHigh1.5G # 改完执行 systemctl daemon-reload systemctl restart 你的服务参数说明MemoryHigh是软限制超过会开始回收MemoryMax是硬限制超过直接触发该 cgroup 的 OOM。两个配合用能在服务失控时只杀它自己不牵连整机。3.2 IO hang 与存储故障D 状态进程背后的设备问题IO hang 比 OOM 更难缠因为进程卡在内核态用户态什么都做不了。典型现象是大量 D 状态进程、vmstat的wa接近 100、iostat里某块盘%util满但吞吐很低。# 看每块盘的 IO 情况 iostat -x 1 5 # 看是否有 IO 错误 dmesg -T | grep -iE I/O error|medium error|reset|timeout # 看块设备是否还在 lsblk cat /proc/mounts # 如果是网络存储NFS/iSCSI检查链路 mount | grep -E nfs|iscsi逻辑说明iostat -x的%util接近 100 且await很高说明设备饱和或故障dmesg里的I/O error、timeout、reset是硬件或链路故障的直接证据。如果是 NFSmount时用了hard选项服务端挂了客户端会一直重试进程就卡在 D 状态。注意NFS 挂载建议加soft,timeo30,retrans3或至少设intr新内核已废弃避免服务端故障时客户端无限等待。但soft有数据一致性风险要按业务权衡。3.3 内核 panic 与硬件故障kdump 是唯一的黑匣子内核 panic 时系统直接停住唯一的取证手段是 kdump——它会在 panic 时用预留内存启动一个捕获内核把崩溃现场的内存镜像vmcore存下来。# 检查 kdump 是否启用 systemctl status kdump cat /sys/kernel/kexec_crash_loaded # 预留崩溃内存在 /etc/default/grub 的 GRUB_CMDLINE_LINUX 里加 # crashkernel512M-2G:256M,2G-64G:512M # 改完更新 grub 并重启 grub2-mkconfig -o /boot/grub2/grub.cfg # Debian/Ubuntu 用 update-grub # panic 后 vmcore 默认在 /var/crash/用 crash 工具分析 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore逻辑说明crashkernel参数给捕获内核预留内存格式是「内存范围:预留大小」要按机器内存调整留太小捕获内核起不来。kexec_crash_loaded返回 1 说明 kdump 就绪。vmcore 是二进制内存镜像必须配合对应内核版本的vmlinux带调试符号才能用crash分析。硬件故障的线索通常在dmesg里MCE、EDAC、Hardware Error、CPU temperature above threshold。这类问题软件层面无解只能换硬件或联系厂商。4. 避坑与排查死机处理里最容易翻车的五个操作死机处理本身就是在高压下操作越急越容易犯错。下面五条都是真实踩过的坑按「现象 → 原因 → 解决」列出来。坑一一上来就reboot -f现场全丢。现象重启后系统恢复正常但过几天同样死机毫无头绪。 原因reboot -f强制重启内核日志、进程状态、vmcore 全部丢失。 解决先走 SysRq 的stlm导出证据再b重启提前配好 kdump 和持久化日志/var/log单独分区或远程 syslog。坑二把 OOM 当成内存泄漏盲目加内存。现象加完内存后死机频率下降但没消失负载依然周期性飙高。 原因OOM 可能是瞬时峰值、内存碎片或 cgroup 配置不当不一定是泄漏。 解决先用dmesg确认 OOM 记录看被杀进程和当时内存分布用MemoryMax限制单服务再决定是否加内存。坑三D 状态进程反复kill -9。现象kill -9毫无反应进程还在越杀越多。 原因D 状态进程不响应信号卡在内核 IO 路径上。 解决别杀去看wchan和iostat定位是哪块设备或哪个存储链路卡住从设备层解决。坑四日志没持久化重启后journalctl -b -1是空的。现象想查上次启动的日志发现 journal 没保存。 原因默认 journal 存在/run内存重启即失。 解决在/etc/systemd/journald.conf设Storagepersistent并确保/var/log/journal存在关键机器再配远程 syslog。坑五kdump 预留内存太小panic 时捕获内核起不来。现象配了 kdump真 panic 时/var/crash里什么都没有。 原因crashkernel预留不足或捕获内核缺少对应驱动。 解决按内存规模调大预留值测试时用echo c /proc/sysrq-trigger主动触发 panic 验证 kdump 是否真能生成 vmcore。5. 把死机处理变成可复现流程一份检查清单和两个进阶技巧死机处理最怕临时发挥我现在的习惯是提前把流程固化成清单出事照着走。下面这份清单可以直接抄配合两个进阶技巧能把「靠运气」变成「靠流程」。阶段动作命令/入口关键点判断分层确认是否真死机ping / nc / 带外控制台区分网络、sshd、内核取证导出内核日志dmesg -T、journalctl -k -b -1先落盘再重启取证触发 SysRqecho s/t/l/m /proc/sysrq-trigger顺序不能乱取证抓进程快照ps D 状态、vmstat、iostat记录 wchan分析对号入座OOM / IO hang / panic / 硬件看关键词恢复安全重启SysRq b 或正常 reboot确认数据已 sync第一个进阶技巧是主动演练。别等真死机才第一次用 SysRq 和 kdump。找一台测试机echo c /proc/sysrq-trigger主动制造 panic验证 kdump 能不能生成 vmcore、crash能不能打开、日志有没有持久化。演练一次真出事时手不抖。# 测试机主动触发 panic验证 kdump 全链路 echo 1 /proc/sys/kernel/sysrq echo c /proc/sysrq-trigger # 重启后检查 ls -lh /var/crash/ crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore逻辑说明echo c触发内核崩溃这是验证 kdump 是否真正可用的唯一可靠方法。参数上要确保sysrq已开启且crashkernel预留足够。演练完记得把测试机的配置和线上对齐。第二个技巧是给关键进程上「免死金牌」并配好监控。用oom_score_adj保护核心进程用 systemd 的MemoryMax限制失控服务再用监控盯住dmesg里的 OOM、IO error、MCE 关键词做到死机前就有预警。# 保护关键进程不被 OOM 杀 echo -1000 /proc/$(pgrep -f 你的核心服务)/oom_score_adj # 用 systemd 限制服务内存防止拖垮整机 # 在 service 文件 [Service] 段加 # MemoryMax2G # MemoryHigh1.5G # OOMPolicystop参数说明OOMPolicystop表示该服务触发 OOM 时只停它自己不影响整机配合MemoryMax形成双层保护。监控侧建议把dmesg -T --levelerr的输出接入告警关键词命中就通知。从那以后我每次上生产机器第一件事就是确认kernel.sysrq开着、kdump 就绪、journal 持久化这三样没配好绝不上线。死机不可怕可怕的是死机后什么都不知道。希望帮到你。本文还有配套的精品资源点击获取