简介这是一份面向Linux运维工程师与系统管理员的故障排查参考资料聚焦系统死机或崩溃后如何有效采集与分析现场信息帮助判断问题源于硬件故障还是应用程序缺陷。资源以doc文档形式交付压缩包内共1个文件体积约47KB内容围绕Core dump、Diskdump与Netdump三种崩溃信息获取机制展开涵盖核心转储的开启与文件路径配置、单机内核转储分区的初始化与vcore文件生成、以及通过远程服务器接收客户端崩溃信息的部署方式。文档对每种方法的适用场景、配置要点与注意事项均有说明例如非HP SCSI设备启用Diskdump时的模块替换与initrd重建以及Netdump对网卡netpoll支持的要求。目前已有527人学习适合需要提升系统稳定性与故障定位效率的运维人员参考可帮助读者在日志缺失的情况下仍能获取有价值的崩溃现场数据缩短排障周期。1. Linux 死机不是玄学从「键盘还能亮吗」开始分层定位Linux 死机最让人抓狂的地方在于它不像 Windows 那样动不动给你一个蓝屏代码。很多时候屏幕就那么定住了鼠标不动SSH 断连但你隐约觉得机器还在转——风扇在响硬盘灯偶尔闪一下。这种「薛定谔的死机」让不少刚接触 Linux 的运维新手直接选择硬重启结果要么数据丢失要么重启后文件系统报错甚至再也起不来。我处理过几十次不同形态的 Linux 死机从虚拟机安装 Linux 蓝屏到生产环境负载飙高导致的假死核心经验只有一条先分层再动手。死机不是一个单一问题它至少涉及硬件层、内核层、用户态进程层、存储 I/O 层四个层面。你要做的第一件事不是敲命令而是判断「死到了哪一层」。键盘 Caps Lock 灯还能不能切换能切换说明内核还在调度大概率是某个用户态进程或图形界面卡死不能切换说明内核已经失去响应问题在更底层。这篇文章面向的是需要实际处理 Linux 死机的运维和开发人员。我会把「怎么判断死机类型」「怎么在不重启的前提下抓现场」「哪些参数和工具能救命」「哪些操作会让情况更糟」一条线讲清楚。如果你手头正好有一台卡死的机器或者想提前给自己留好后悔药下面的内容可以直接照着做。2. 死机现场的分层判断与信息采集2.1 用键盘灯和 SysRq 判断内核是否还活着很多人不知道Linux 内核内置了一套「魔术键」机制叫 SysRq。它能在系统几乎完全卡死的情况下直接和内核对话。前提是内核编译时启用了CONFIG_MAGIC_SYSRQ绝大多数发行版默认开启。判断步骤很简单按一下键盘上的 Caps Lock 或 Num Lock看指示灯有没有变化。如果灯能切换说明内核调度器还在工作问题大概率在用户态。如果灯完全没反应尝试 SysRq 组合键Alt SysRq H看终端有没有输出帮助信息。SysRq 键在大多数键盘上就是 Print Screen 键。如果Alt SysRq H有输出说明内核还活着只是用户态卡死了。这时候你可以按顺序执行一套安全的救援操作# 以下操作通过键盘组合键完成不是终端命令 # Alt SysRq R 解除键盘原始模式 # Alt SysRq E 向所有进程发送 SIGTERM让它们优雅退出 # Alt SysRq I 向所有进程发送 SIGKILL强制杀死 # Alt SysRq S 同步所有挂载的文件系统 # Alt SysRq U 重新挂载所有文件系统为只读 # Alt SysRq B 立即重启这套顺序被称为「R-E-I-S-U-B」是 Linux 内核文档里推荐的安全重启流程。它的逻辑是先让进程退出再把内存里的脏数据刷到磁盘最后才重启。直接按电源键跳过 S 和 U很可能导致文件系统损坏。注意Alt SysRq B是立即重启不会给进程任何清理时间。只有在 E 和 I 都无效、系统完全无响应时才用。如果 SysRq 完全没反应说明内核已经死了。这时候只能硬重启但重启前尽量等 30 秒以上让磁盘缓存有机会落盘。2.2 用 SSH 和串口控制台抓取内核日志如果机器还能通过网络访问哪怕 SSH 登录后命令执行极慢也要优先尝试抓日志。内核环形缓冲区里的信息是定位死机原因的关键。# 查看内核环形缓冲区最后 200 行 dmesg | tail -n 200 # 如果 dmesg 卡住尝试用 journalctl 查看本次启动的日志 journalctl -k -b -0 --no-pager | tail -n 200 # 查看是否有 OOM killer 记录 dmesg | grep -i out of memory dmesg | grep -i oom-killer # 查看是否有硬件错误 dmesg | grep -i error\|fail\|timeout\|resetdmesg读的是内核环形缓冲区即使系统卡顿这个命令通常也能返回。重点看几个关键词oom-killer说明内存耗尽触发了杀进程机制I/O error或ata bus error指向磁盘或控制器故障soft lockup和hard lockup是 CPU 卡死的直接证据。如果 SSH 也连不上但机器有串口控制台比如服务器上的 IPMI SOL 或虚拟机串口通过串口登录后同样可以执行上述命令。串口控制台的优势是它不依赖网络协议栈只要内核还能调度串口驱动就能输出信息。2.3 用 top 和 ps 区分「真死」与「假死」有一种情况经常被误判为死机系统负载极高所有命令响应极慢但并没有完全卡死。这时候用top或ps能看到大量进程处于 D 状态不可中断睡眠。# 查看处于 D 状态的进程 ps -eo pid,stat,comm | awk $2 ~ /D/ {print} # 查看负载和 CPU 等待 I/O 的比例 top -b -n 1 | head -n 5 # 查看具体是哪个进程在占用 I/O iotop -o -b -n 1D 状态进程通常是在等待磁盘 I/O 或网络文件系统响应。如果大量进程卡在 D 状态而 CPU 的waI/O 等待指标很高说明存储层出了问题。这时候重启不一定能解决因为重启过程中可能同样卡在 I/O 上。我遇到过一台机器SSH 能连上但执行任何命令都要等十几秒top显示wa高达 90%。最后定位到是一块 SSD 的固件 bug 导致 I/O 队列堵塞。这种情况换盘才是正解重启只是暂时缓解。3. 内核崩溃与硬件故障的排查路径3.1 配置 kdump 抓取内核崩溃现场如果死机已经严重到内核 panic屏幕上可能会留下一段 call trace但更多时候机器直接重启什么也看不到。kdump 就是为这种场景准备的它会在内核崩溃时启动一个备用内核把第一个内核的内存镜像保存下来。配置 kdump 的步骤# 安装 kexec-tools以 RHEL/CentOS 为例 yum install -y kexec-tools # 设置 crashkernel 预留内存编辑 grub 配置 # 在 GRUB_CMDLINE_LINUX 中添加 crashkernelauto 或 crashkernel256M vi /etc/default/grub # 重新生成 grub 配置 grub2-mkconfig -o /boot/grub2/grub.cfg # 启用并启动 kdump 服务 systemctl enable kdump systemctl start kdump # 验证 kdump 是否就绪 kdumpctl statuscrashkernelauto让系统自动预留合适大小的内存给捕获内核。对于内存较大的机器建议手动指定crashkernel512M或更大否则捕获内核可能因为内存不足启动失败。内核崩溃后vmcore 文件默认保存在/var/crash/下。分析 vmcore 需要crash工具和对应的内核调试符号包# 安装 crash 工具 yum install -y crash kernel-debuginfo # 分析 vmcore crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/*/vmcore # 进入 crash 交互界面后常用命令 # bt 查看崩溃时的调用栈 # log 查看内核日志 # ps 查看进程状态 # vm 查看内存使用bt命令输出的调用栈是定位 panic 原因的核心依据。如果栈顶是某个驱动函数基本可以锁定是驱动问题如果是内存管理函数可能是内存耗尽或内存损坏。3.2 用 memtest86 排除内存故障内存故障是 Linux 死机最隐蔽的原因之一。它不像磁盘故障那样有明确的 I/O 错误而是表现为随机的段错误、内核 panic、进程莫名被杀。如果你发现机器死机没有规律重启后又能正常跑一段时间优先怀疑内存。memtest86 是一个独立的内存测试工具需要制作启动 U 盘从 U 盘启动后它会自动循环测试内存。测试时间越长越好建议至少跑满两轮完整测试。如果出现任何红色错误行直接更换内存条。在 Linux 系统内也有一个快速检查方法# 查看内存硬件信息 dmidecode -t memory | grep -E Size|Speed|Manufacturer|Serial # 查看 EDAC 报告的内存错误需要内核支持 grep -i edac\|ecc /var/log/messages dmesg | grep -i edac\|ecc\|memory error如果 EDAC 报告了可纠正或不可纠正的内存错误说明内存条已经不可靠。可纠正错误虽然不会立即导致死机但数量增多后系统稳定性会急剧下降。3.3 磁盘和文件系统故障的早期信号磁盘故障导致的死机通常有前兆。smartd服务会监控磁盘的 SMART 属性在磁盘彻底坏掉之前发出警告。# 查看磁盘 SMART 健康状态 smartctl -H /dev/sda # 查看关键 SMART 属性 smartctl -A /dev/sda | grep -E Reallocated|Pending|Uncorrectable|CRC # 查看内核有没有报告 I/O 错误 dmesg | grep -i I/O error\|medium error\|sense key重点关注三个属性Reallocated_Sector_Ct重映射扇区数持续增长说明盘片有坏道Current_Pending_Sector待映射扇区数大于 0 说明有读不出来的扇区Offline_Uncorrectable离线不可纠正错误大于 0 说明磁盘已经不可信。文件系统层面ext4 在遇到错误时会根据errors挂载选项决定行为。默认是errorscontinue也就是记录错误后继续运行。如果改成errorsremount-ro文件系统会在检测到错误时重新挂载为只读避免错误扩散。对于生产环境我一般建议设置errorsremount-ro至少能保住已有数据。# 查看当前挂载参数 mount | grep -E ext4|xfs # 在 /etc/fstab 中为 ext4 分区添加 errorsremount-ro # /dev/sda1 / ext4 defaults,errorsremount-ro 0 14. 死机排查的避坑与常见问题4.1 硬重启后文件系统报错甚至无法挂载现象死机后长按电源键强制关机重新开机时系统卡在 fsck 阶段或者直接进入 emergency mode提示文件系统损坏。原因强制断电时内存中还有大量脏页没有写回磁盘。ext4 的日志机制虽然能保证元数据一致性但无法保证数据完整性。如果脏页涉及文件系统结构就会导致元数据损坏。解决首先不要反复重启。在 fsck 提示时让 fsck 自动修复。如果 fsck 无法修复用 Live CD 启动手动运行fsck -y /dev/sda1。修复后挂载为只读尽快备份数据。预防措施是配置 SysRq 的 S 和 U 步骤或者使用带电池保护的 RAID 卡。4.2 OOM killer 杀掉了关键进程但系统仍然卡死现象dmesg 里有 oom-killer 记录但杀掉进程后系统没有恢复反而越来越卡。原因OOM killer 选择杀死的进程可能不是内存占用最大的那个或者被杀进程持有大量锁资源导致其他进程无法继续。更糟的情况是被杀进程是 systemd 或 sshd导致你无法登录处理。解决提前配置systemd-oomd或调整/proc/sys/vm/panic_on_oom。对于关键业务机器设置panic_on_oom1让内核在 OOM 时直接 panic 并触发 kdump比半死不活更好排查。另外可以用 cgroup 限制关键服务的内存使用避免它们被 OOM killer 选中。# 临时设置 OOM 时 panic echo 1 /proc/sys/vm/panic_on_oom # 永久生效 echo vm.panic_on_oom1 /etc/sysctl.conf sysctl -p4.3 大量 D 状态进程导致负载飙升但 CPU 空闲现象top显示 load average 很高但 CPU 使用率很低wa很高大量进程处于 D 状态。原因通常是 NFS 挂载点无响应、iSCSI 存储断连、或者本地磁盘出现坏道导致 I/O 请求无法完成。D 状态进程无法被 kill -9 杀死因为它们在内核态等待 I/O 完成。解决如果是 NFS尝试umount -f强制卸载但可能同样卡住。更可靠的方法是重启 NFS 客户端服务或直接重启机器。对于本地磁盘检查 dmesg 中的 I/O 错误尽快更换磁盘。预防措施是给 NFS 挂载添加soft,timeo30,retrans3选项让 I/O 超时后返回错误而不是无限等待。4.4 内核 soft lockup 被误判为硬件故障现象dmesg 中出现watchdog: BUG: soft lockup - CPU#0 stuck for 22s系统响应极慢但没完全死。原因soft lockup 是某个内核函数占用 CPU 超过阈值没有让出。常见原因包括驱动 bug、内核死循环、虚拟化环境 CPU 被过度分配。它不一定是硬件问题。解决先看 lockup 的调用栈定位是哪个模块。如果是虚拟化环境检查宿主机 CPU 是否超卖。如果是驱动问题升级或降级驱动。临时缓解可以调整 watchdog 阈值# 查看当前阈值 cat /proc/sys/kernel/watchdog_thresh # 临时调大阈值单位秒 echo 30 /proc/sys/kernel/watchdog_thresh4.5 图形界面卡死但系统实际正常现象桌面环境完全无响应鼠标键盘都没反应但 SSH 能登录系统负载正常。原因Xorg 或 Wayland 合成器崩溃或者显卡驱动卡死。这种情况在安装了专有显卡驱动的机器上尤其常见。解决通过 SSH 登录后重启显示管理器或者切换到其他 TTYCtrl Alt F2登录后杀掉图形会话。如果经常发生考虑更换开源驱动或降级内核。对于服务器直接不安装图形界面是最省心的选择。5. 把死机排查变成可复用的应急流程5.1 提前配置一套「死机后悔药」与其等死机了手忙脚乱不如提前把该配的都配上。我一般在每台 Linux 机器交付前做这几件事第一确认 SysRq 可用。cat /proc/sys/kernel/sysrq返回值大于 0 即可。如果是 0通过echo 1 /proc/sys/kernel/sysrq临时开启并在/etc/sysctl.conf中写入kernel.sysrq1永久生效。第二配置 kdump 并验证。kdumpctl status显示 operational 才算就绪。很多机器装了 kexec-tools 但 crashkernel 内存没预留够kdump 实际起不来。第三部署监控。用 Prometheus node_exporter 采集node_pressure_io_stalled、node_memory_MemAvailable_bytes、node_load1等指标在死机前就能收到告警。特别是 PSIPressure Stall Information指标它能比 load average 更早反映资源争抢。第四配置串口控制台或 IPMI SOL。当网络和 SSH 都不可用时这是最后的救命通道。在 grub 中添加consolettyS0,115200并启用 getty 即可。5.2 用 PSI 指标提前发现死机前兆PSI 是 Linux 4.20 之后引入的资源压力指标它比传统的 load average 更精确。/proc/pressure/下有三个文件cpu、memory、io。每个文件里的some和full行表示至少有一个任务或所有任务因为资源不足而停滞的时间比例。# 查看 I/O 压力 cat /proc/pressure/io # 输出示例 # some avg1045.23 avg6032.11 avg30015.67 total123456789 # full avg1030.12 avg6020.45 avg3008.90 total98765432full行的avg10超过 20% 就说明 I/O 已经成为严重瓶颈系统离假死不远了。这时候应该立即排查是哪个进程在疯狂读写而不是等它彻底卡死。# 找出 I/O 压力最大的进程 iotop -o -b -n 1 -P # 或者用 pidstat 查看每个进程的 I/O 等待 pidstat -d 1 55.3 一个真实案例的排查时间线最后分享一个我处理过的案例。一台运行 MySQL 的服务器在凌晨三点突然失去响应SSH 超时但监控显示 CPU 和内存都正常。我的处理顺序是先通过 IPMI SOL 登录串口控制台发现内核还在响应但所有 MySQL 相关进程都是 D 状态。dmesg显示大量blk_update_request: I/O error指向/dev/sdb。进一步用smartctl -A /dev/sdb发现Current_Pending_Sector高达 128。结论是磁盘坏道导致 MySQL 的 I/O 请求无法完成进程卡在 D 状态进而拖死了整个系统。处理方式是通过串口控制台执行Alt SysRq S尝试同步失败然后Alt SysRq U重挂载为只读成功最后Alt SysRq B重启。重启后从备份恢复了 MySQL 数据更换了故障磁盘。这次经历让我养成了一个习惯任何生产机器上线前必须验证 SysRq 可用、kdump 就绪、串口控制台能登录。这三样东西平时用不到但死机的时候它们就是你和数据之间最后的屏障。希望帮到你。本文还有配套的精品资源点击获取