企业官网建设流程全解析

简介：这是一份面向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，绝大多数发行版默认开启。

判断步骤很简单：

1. 按一下键盘上的 Caps Lock 或 Num Lock，看指示灯有没有变化。
2. 如果灯能切换，说明内核调度器还在工作，问题大概率在用户态。
3. 如果灯完全没反应，尝试 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\|reset"

dmesg读的是内核环形缓冲区，即使系统卡顿，这个命令通常也能返回。重点看几个关键词：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 1

D 状态进程通常是在等待磁盘 I/O 或网络文件系统响应。如果大量进程卡在 D 状态，而 CPU 的wa（I/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 中添加 crashkernel=auto 或 crashkernel=256M vi /etc/default/grub # 重新生成 grub 配置 grub2-mkconfig -o /boot/grub2/grub.cfg # 启用并启动 kdump 服务 systemctl enable kdump systemctl start kdump # 验证 kdump 是否就绪 kdumpctl status

crashkernel=auto让系统自动预留合适大小的内存给捕获内核。对于内存较大的机器，建议手动指定crashkernel=512M或更大，否则捕获内核可能因为内存不足启动失败。

内核崩溃后，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挂载选项决定行为。默认是errors=continue，也就是记录错误后继续运行。如果改成errors=remount-ro，文件系统会在检测到错误时重新挂载为只读，避免错误扩散。对于生产环境，我一般建议设置errors=remount-ro，至少能保住已有数据。

# 查看当前挂载参数 mount | grep -E "ext4|xfs" # 在 /etc/fstab 中为 ext4 分区添加 errors=remount-ro # /dev/sda1 / ext4 defaults,errors=remount-ro 0 1

4. 死机排查的避坑与常见问题

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_oom=1让内核在 OOM 时直接 panic 并触发 kdump，比半死不活更好排查。另外可以用 cgroup 限制关键服务的内存使用，避免它们被 OOM killer 选中。

# 临时设置 OOM 时 panic echo 1 > /proc/sys/vm/panic_on_oom # 永久生效 echo "vm.panic_on_oom=1" >> /etc/sysctl.conf sysctl -p

4.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,timeo=30,retrans=3选项，让 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_thresh

4.5 图形界面卡死但系统实际正常

现象：桌面环境完全无响应，鼠标键盘都没反应，但 SSH 能登录，系统负载正常。

原因：Xorg 或 Wayland 合成器崩溃，或者显卡驱动卡死。这种情况在安装了专有显卡驱动的机器上尤其常见。

解决：通过 SSH 登录后重启显示管理器，或者切换到其他 TTY（Ctrl + Alt + F2）登录后杀掉图形会话。如果经常发生，考虑更换开源驱动或降级内核。对于服务器，直接不安装图形界面是最省心的选择。

5. 把死机排查变成可复用的应急流程

5.1 提前配置一套「死机后悔药」

与其等死机了手忙脚乱，不如提前把该配的都配上。我一般在每台 Linux 机器交付前做这几件事：

第一，确认 SysRq 可用。cat /proc/sys/kernel/sysrq返回值大于 0 即可。如果是 0，通过echo 1 > /proc/sys/kernel/sysrq临时开启，并在/etc/sysctl.conf中写入kernel.sysrq=1永久生效。

第二，配置 kdump 并验证。kdumpctl status显示 operational 才算就绪。很多机器装了 kexec-tools 但 crashkernel 内存没预留够，kdump 实际起不来。

第三，部署监控。用 Prometheus node_exporter 采集node_pressure_io_stalled、node_memory_MemAvailable_bytes、node_load1等指标，在死机前就能收到告警。特别是 PSI（Pressure Stall Information）指标，它能比 load average 更早反映资源争抢。

第四，配置串口控制台或 IPMI SOL。当网络和 SSH 都不可用时，这是最后的救命通道。在 grub 中添加console=ttyS0,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 avg10=45.23 avg60=32.11 avg300=15.67 total=123456789 # full avg10=30.12 avg60=20.45 avg300=8.90 total=98765432

full行的avg10超过 20% 就说明 I/O 已经成为严重瓶颈，系统离假死不远了。这时候应该立即排查是哪个进程在疯狂读写，而不是等它彻底卡死。

# 找出 I/O 压力最大的进程 iotop -o -b -n 1 -P # 或者用 pidstat 查看每个进程的 I/O 等待 pidstat -d 1 5

5.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 就绪、串口控制台能登录。这三样东西平时用不到，但死机的时候，它们就是你和数据之间最后的屏障。希望帮到你。

本文还有配套的精品资源，点击获取