简介系统崩溃后的信息收集一直是Linux运维中的难点尤其当系统死机且日志无记录时故障定位更加困难。这份doc文档面向Linux系统管理员与运维人员聚焦Core dump、Diskdump、Netdump三种崩溃信息收集机制从配置步骤到适用场景均有清晰说明。Core dump适合调试应用程序错误通过开启内核转储生成core文件Diskdump则无需网络即可将内核崩溃时的内存与CPU状态保存到保留分区重启后再生成vmcoreNetdump面向不支持磁盘转储的红旗等系统可远程收集崩溃现场。文档还补充了启用core dump的具体命令、diskdump设备初始化、netdump服务器与客户端的连接测试以及网卡netpoll支持判断方法方便读者按步骤落地。资源包内含1个doc文档容量仅47KB短小精悍便于快速查阅和收藏目前已有528人学习内容有助于系统崩溃后的快速诊断降低排查故障的时间成本提升系统稳定性。1. Linux操作系统死机处理方法先分清“假死”还是“真死”再决定按不按重启键凌晨三点服务器告警电话把你从床上拽起来。远程连上去ping 通SSH 连不上机房同事到现场一看屏幕定格在某个命令的输出上键盘鼠标全没反应。这时候你最需要的是冷静判断这到底是 X11 桌面卡死、某个进程把 CPU 占满导致的“假死”还是内核彻底 hang 住、连中断处理器都失去响应的“真死”Linux 操作系统死机处理方法的核心不是教你无脑按电源键强制重启而是先花两分钟确认死机层级再用 SysRq 魔术键做受控强制重启最后从日志里找到元凶。这套方法适合所有 Linux 使用者——从刚装好系统的桌面用户到守着几百台服务器的运维工程师。本文要解决的就是“死机了怎么办”以及“下次怎么不死”。2. 用 SysRq 魔术键做受控强制重启REISUB 序列与它的内核原理2.1 先别按电源键3 个命令判断死机级别系统“看起来死了”的时候第一反应应该是确认内核是否还活着。我见过太多人一看到屏幕卡住就长按电源键结果重启后文件系统损坏损失比死机本身还大。判断死机级别最快的方法是按CtrlAltF2或 F3~F6尝试切换虚拟终端。如果屏幕切到了纯文本登录界面说明内核和进程调度都正常只是图形界面卡了如果切换没反应再试键盘的Caps Lock键看指示灯会不会亮。指示灯是判断内核是否响应的关键信号。CapsLock 的亮灭由内核的键盘驱动直接处理不经过图形界面。如果按下去灯不亮说明内核已经失去对中断的基本响应这是真正意义上的“死机”如果灯能切换说明内核还活着只是某些进程把资源耗尽或者设备驱动卡死了。这时候可以再试 SSH 远程登录能登录就说明网络栈和进程调度还正常问题往往出在某个失控进程上。# 系统还能响应 SSH 时先看负载和进程状态 uptime top -bn1 | head -20 # 看是不是有进程进了 D 状态不可中断睡眠 ps -eo pid,stat,wchan:32,cmd | grep ^ *[0-9] | awk $2 ~ /D/这段排查的逻辑是uptime看 1/5/15 分钟负载是否异常飙升top看 CPU 占用最高的进程ps过滤出 D 状态进程——这类进程通常在等待 IO 完成如果大量进程停在 D 状态且 IO 设备无响应比如 NFS 挂载的远程存储断开系统就会表现得像死机但内核其实还活着。这种情况按 SysRq 有用按电源键反而可能让未完成的 IO 写操作直接丢失。2.2 SysRq 魔术键REISUB 的每个字母在做什么SysRqSystem Request是内核内置的“魔术键”机制它让内核在即使图形界面和大部分用户态进程卡死的情况下仍然响应特定键盘组合执行紧急操作。原理在于 SysRq 的响应路径跑在中断上下文里不依赖 X11、不依赖 systemd、不依赖进程调度器——只要 CPU 还能响应键盘中断它就能工作。这是它被称为“最后一道后悔药”的原因。最常见的受控重启序列是REISUB每个字母对应一个内核动作顺序非常重要不能乱按按键内核动作作用RunRaw从 X11 手里拿回键盘原始控制权EtErminate向所有进程发送 SIGTERM礼貌请求退出IkIll向所有进程发送 SIGKILL强制结束SSync把内存中的脏数据写回磁盘UUnmount将所有文件系统重新挂载为只读BreBoot立即重启为什么是先 TERM 再 KILL因为要给进程一次清理现场的机会——关闭文件、释放锁、写日志。为什么 KILL 之后还要 Sync 和 Unmount因为强制杀进程不能保证内核缓存都落盘先 Sync 再 Unmount 把数据完整写回磁盘重启后文件系统一致性检查fsck的报错概率会大幅降低。整个序列执行时可以按住Alt SysRq不放依次按REISUB每按一个字母等 2~3 秒让内核完成对应动作。笔记本键盘上SysRq通常印在PrintScreen键上需要同时按Fn。2.3 服务器上没有键盘用 echo 触发 SysRq 或走 IPMI生产环境里很多服务器没有接键盘显示器机房人也不一定随时有空。这时候可以把 SysRq 从“键盘组合”切换成“文件写入”来触发。内核提供了一个 proc 接口/proc/sysrq-trigger往里面写单个字符就能触发对应动作和按键盘的效果完全一样。这个接口在系统还能通过 SSH 登录时特别好用——你不需要物理接触机器远程就能做受控重启。# 确认 sysrq 内核参数已开启 cat /proc/sys/kernel/sysrq # 如果输出是 0先临时开启 echo 1 /proc/sys/kernel/sysrq # 永久开启 echo kernel.sysrq1 /etc/sysctl.d/99-sysrq.conf sysctl --system # 远程触发完整 REISUB按顺序每步间隔几秒 echo r /proc/sysrq-trigger; sleep 3 echo e /proc/sysrq-trigger; sleep 3 echo i /proc/sysrq-trigger; sleep 3 echo s /proc/sysrq-trigger; sleep 3 echo u /proc/sysrq-trigger; sleep 3 echo b /proc/sysrq-trigger这里有几个值得注意的地方。kernel.sysrq的值不只是 0 和 1——0 表示完全关闭1 表示允许所有功能除此之外还有按位控制的写法比如 4 表示只允许sync但实际运维中直接设 1 最省事特殊安全要求的环境除外。触发r之后键盘控制权从 X11 回收如果 SSH 还活着后续的echo命令依然可以执行因为 proc 接口不依赖图形栈。如果你用的是带 IPMI/BMC 的服务器也可以用ipmitool chassis power cycle做硬件级重启但那是最后手段先用 SysRq 能保住文件系统完整性。3. 死机后 30 分钟排查从 journalctl 和 dmesg 里找出真正的元凶3.1 日志关键词panic、hung_task、oom-killer、watchdog 各有各的现场重启回来后第一件事不是急着把服务拉起来而是先看日志把死机的根因找出来。很多人跳过这一步直接恢复业务结果同一台机器一周后又死一次。真正的故障案例告诉我们死机不是随机事件日志里一定留着线索。排查顺序是先看内核日志再看系统日志最后看硬件日志。# 查看当前启动的内核日志 journalctl -k -b 0 | tail -200 # 查看上一次启动的内核日志-b -1 表示上一次启动 journalctl -k -b -1 | tail -200 # 带时间戳查看方便和死机时间对齐 dmesg -T | tail -100 # 如果系统没有启用 journald 持久化看传统日志文件 tail -200 /var/log/messagesjournalctl -k -b -1是排查死机现场最实用的一条命令它读的是上一次开机周期产生的内核环形缓冲区日志即使那次死机发生在半夜只要 journald 配置了持久化你就能看到死机前的最后几百行内核输出。日志里需要重点找这几个关键词每个都代表不同的故障类型日志关键词通常含义下一步方向kernel panic内核致命错误主动停机检查是否有BUG:和调用栈配合 kdump 分析hung_task某个任务阻塞超 120 秒查 IO 设备、NFS 挂载、磁盘控制器Out of memory/oom-killer内存耗尽触发 OOM 杀进程查dmesg里的进程内存占用考虑调 swapwatchdog/soft lockupCPU 某核心长时间不调度查驱动死循环、中断风暴、硬件故障Call Trace内核调用栈记录函数名用crash或在线查对应内核源码MCE/mce:硬件机器检查错误多半是内存或 CPU 故障跑mcelog确认这些关键词的分布有个规律如果是内存条坏了日志里会出现大量MCE错误如果是 NFS 服务端宕机导致客户端 IO 阻塞你会看到一堆进程卡在 D 状态然后触发hung_task如果是某个内核驱动 bug通常是panic加一长串Call Trace。顺着关键词找根因比从头读几百行日志效率高得多。3.2 从 abrt 和 kdump 里拿内核转储死机现场的黑匣子光有启动日志还不够很多时候日志里只有“结果”没有“原因”。要拿到完整的死机现场得靠内核转储kernel dump。Red Hat 系发行版默认装了 abrtAutomated Bug Reporting Tool它会在内核 panic 时自动保存现场数据到/var/crash/目录。Ubuntu/Debian 系则用kdump-tools配合crashkernel引导参数实现同样的效果。# 查看是否有 crashes 记录 abrt-cli list # 查看 crash 目录内容 ls -lh /var/crash/ # 看 vmcore 的详细信息 file /var/crash/*/vmcorevmcore文件就是内核死机瞬间内存的完整镜像小则几百 MB大则几个 GB它就是死机现场的黑匣子。拿到 vmcore 之后可以用crash工具结合带调试符号的vmlinux内核镜像做回溯分析定位到具体的内核函数和调用路径。关于 kdump 的配置和 crash 的用法我放在第 6 章单独展开——这里先记住一件事如果/var/crash/是空的而系统确实 panic 过说明 kdump 服务没配好下次死机依然没有现场数据。3.3 外因排查硬件、电源、温度怎么从日志里找线索内核日志查完了没发现异常或者只有零散的 MCE 错误就该把视线转到硬件层面。Linux 死机有很大比例是硬件不稳定引起的尤其是内存、电源和散热。内存错误通常会在dmesg里留下MCE或者EDAC记录可以持续观察mcelog的输出电源问题表现为系统突然断电式死机、没有日志、没有 panic——因为电源都没了内核根本没机会说话温度过热则往往在死机前的日志里出现 thermal 相关的警告。# 查看内存控制器错误记录 mcelog --client 2/dev/null || grep -i mce /var/log/messages # 查看 CPU 温度历史如果系统里有传感器 sensors 2/dev/null | grep -A2 Core # 检查磁盘健康状态 smartctl -a /dev/sda | grep -E Reallocated|Pending|Temperature一个很容易被忽略的排查方向是“死机的时间规律”。如果系统总在凌晨 2~4 点死机优先怀疑定时任务——cron里的备份脚本、日志切割、系统更新都有可能是导火索如果总在业务高峰死机优先怀疑资源耗尽和并发瓶颈。时间规律能帮你缩小排查范围避免在硬件和软件之间来回折腾。这一条没人写进文档里但经验丰富的运维都会先问一句“死机有规律吗”4. 死机预防的参数清单sysctl、watchdog 与日志持久化的三个设置4.1 sysctl 参数让内核自己处理卡死而不是傻等很多死机本来是可以自愈的只是因为内核默认参数太“耐心”了。比如默认的hung_task_timeout_secs是 120 秒任务阻塞超过 2 分钟才触发警告如果调成 30 秒内核能更早介入。再比如kernel.panic默认是 0内核 panic 之后直接停机等人工干预服务器就瘫在那儿了。这些参数改起来不复杂但对“死机后能否自动恢复”影响巨大。# /etc/sysctl.d/99-deadlock-prevention.conf # panic 后 10 秒自动重启避免服务器长时间瘫着 kernel.panic 10 # 把 hung task 检测时间从默认 120 秒缩短到 60 秒 kernel.hung_task_timeout_secs 60 # 开启 NMI watchdog检测硬锁死hard lockup kernel.nmi_watchdog 1 # 开启软锁死soft lockup检测 kernel.softlockup_all_cpu_backtrace 1 # OOM 时不要 panic而是触发 oom-killer 杀进程保系统 vm.panic_on_oom 0这些参数的意义要分开讲。kernel.panic10解决的是“死透了没人管”的问题——内核 panic 后 10 秒自动重启服务能尽快恢复代价是丢失死机瞬间的现场除非配了 kdump。kernel.hung_task_timeout_secs60让内核更早报告 IO 阻塞早报比晚报好因为阻塞时间越长文件系统缓冲区里堆积的脏页越多Sync 时压力越大。nmi_watchdog和softlockup背靠背工作前者检测 CPU 超过一定时间不响应 NMI 中断后者检测软中断长时间不调度。最后一条vm.panic_on_oom保持 0 就行——大多数场景下让 OOM killer 杀掉几个进程换系统存活比重启整个机器更划算。4.2 systemd 层看门狗服务卡死时自动拉起而不是扛到死机sysctl 管的是内核systemd 管的是用户态服务。生产环境中还有一种常见的“伪死机”某个关键服务卡住不响应层层调用全部阻塞最后整个系统像死了一样。systemd 提供了WatchdogSec机制来解决这个问题——服务需要定期向 systemd 汇报“我还活着”超时未汇报就被强制杀掉并重启。# 编辑服务单元的 watchdog 配置 # /etc/systemd/system/myapp.service.d/watchdog.conf [Service] # 每 30 秒需要收到一次心跳超时则重启该服务 WatchdogSec30 Restarton-failure RestartSec5 # 服务启动超过 90 秒算启动失败 TimeoutStartSec90# 重新加载配置并确认生效 systemctl daemon-reload systemctl show myapp.service | grep -E Watchdog|Restart使用WatchdogSec有个前提你的程序代码里要实现心跳上报调用sd_notify(WATCHDOG1)接口。很多应用默认没做这个事所以配置了也不生效——这正是不少运维在这个设置上翻车的原因。如果你的服务是第三方开发的闭源程序不支持 sd_notify可以退而求其次用Restarton-failure保证“进程退出就拉起”至少比放任它死在那儿强。systemd 本身也有两个看门狗参数写在/etc/systemd/system.conf里RuntimeWatchdogSec60让 systemd 自己监视内核RebootWatchdogSec300可以设置硬件看门狗超时自动重启但后者依赖硬件 WDT 芯片虚拟机里起不到作用。4.3 日志持久化别让死机把日志也带走了排查死机最痛苦的场景不是日志太多而是死机之后发现日志根本不在。journald 默认把日志存在内存文件系统/run/log/journal/里系统一重启内存一清死机前的最后痕迹全没了。这就是为什么很多运维吐槽“死机像失忆”——不是没有日志是没保存下来。解决方法是把 journald 改成持久化存储并且把关键内核日志同时转发到传统文件。# /etc/systemd/journald.conf [Journal] # 持久化到 /var/log/journal不再使用内存文件系统 Storagepersistent # 同步落盘间隔默认 5 分钟改成 1 分钟减少崩溃丢日志 SyncIntervalSec1m # 限制日志最大体积防止写满系统盘 SystemMaxUse4G# 修改后重启 journald 并验证持久化目录 systemctl restart systemd-journald mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal journalctl --disk-usageStoragepersistent生效后系统会自动创建/var/log/journal目录之后所有日志都会写入磁盘。SyncIntervalSec1m让日志每 1 分钟同步一次最多丢失一分钟的日志代价是有一定的 IO 开销对现代服务器来说可以忽略。SystemMaxUse4G防止日志无限增长——这一点经常被忽略默认限制是系统盘容量的 10%如果系统盘很大会导致日志吃满磁盘反而诱发新故障。配好日志持久化之后第 3 章里的journalctl -k -b -1才能稳定工作。5. 避坑指南6 个一起死机就翻车的处理习惯5.1 现象屏幕卡住按 CtrlAltF1 没反应直接断电重启很多新手看到切换终端没反应就认定内核死了长按电源键强制关机。重启后往往伴随文件系统损坏fsck跑半小时才能进系统。原因不是内核真死了而是 X11 的键盘输入处理卡住虚拟终端切换请求被阻塞。解决断电之前先试远程 SSH。能 SSH 登录就说明内核和网络栈活着走/proc/sysrq-trigger做受控重启数据完整性能大幅提升。如果确实连 SSH 都不通再按电源键不迟但按键时长控制在 4 秒内别按 10 秒以上触发硬件强制断电。5.2 现象执行 REISUB 序列系统完全没反应按了AltSysRqREISUB内核既不重启也不落盘像按在棉花上。最常见原因是内核参数kernel.sysrq被设为 0SysRq 功能被完全禁用这在某些安全加固过的服务器上很常见。另一种可能笔记本厂商把SysRq键映射到了需要按Fn组合才能触发的位置直接按 PrintScreen 没有效果。解决提前在系统健康时检查/proc/sys/kernel/sysrq的值确认是 1笔记本用户实测AltFnPrintScreen是否有效。已经死机且 SysRq 无效时只剩断电一条路——但以后记得把kernel.sysrq写进 sysctl 配置让它在首次启动时就生效。5.3 现象重启后文件系统检查报错部分数据丢失死机时大量未写盘的数据存在内核页缓存里直接断电或 PCIe 总线异常会导致缓存数据永久丢失。特别是数据库和日志类应用刚写入还没有fsync的数据几乎必丢。原因是没有在重启前执行sync或者 REISUB 序列里跳过了S和U步。解决形成肌肉记忆——从 R 到 B一个字母都不许跳。时间再紧Ssync和Uunmount不能省。对数据库服务器还应在应用层开启双写或同步提交从架构上降低对内核落盘时机的依赖。5.4 现象死机后日志目录空空如也现场全无重启后想看死机前发生了什么/var/log/messages和journalctl都是空的没有任何 panic 记录。原因是 journald 默认用内存文件系统存日志断电后内容全部蒸发或者虽然配置了持久化但Storageauto在/var/log/journal不存在时会静默回退到内存模式。解决按第 4.3 节的配置设Storagepersistent重启后跑一次journalctl --disk-usage确认落盘生效。建议所有生产机器都做这一步这是“死机后能破案”的前提。5.5 现象内核 panic 后系统自动重启但反复死在同一位置设了kernel.panic10之后机器确实自动重启了但起来没几分钟又 panic陷入死循环。原因只设置了“重启”没设置“取证”每次 panic 的真实原因没有被记录下来。自动重启解决了“恢复”问题但没解决“根因”。解决把 panic 重启和 kdump 搭配起来——panic 发生时先由 kdump 抓取 vmcore 再重启让每次死机都留下现场证据。这样哪怕死机持续反复你手里也有足够的数据去分析根因。6. 把重启变成“带证据的重启”kdump 采集 vmcore 与 crash 快速分析谈到“带证据的重启”就必须配置 kdump。这套机制的原理是内核启动时预留一块内存crashkernel参数系统 panic 时主内核不直接停机而是启动一个捕获内核把内存镜像写入磁盘形成 vmcore然后才重启。配置流程以 CentOS/RHEL 和 Ubuntu 为例有差异但思路一致# 以 root 安装 kdump 工具发行版不同包名有差异 # RHEL/CentOS: yum install kexec-tools # Ubuntu/Debian: apt install linux-crashdump # 确认 crashkernel 引导参数已加入 grep crashkernel /proc/cmdline # 如果没加编辑 GRUB 配置并重建引导 # RHEL: /etc/default/grub 中 GRUB_CMDLINE_LINUX 追加 crashkernel256M # Ubuntu: /etc/default/grub.d/kdump-tools.cfg 通常已配置 # 启用并启动 kdump 服务 systemctl enable --now kdump systemctl status kdump配置完成后可以做一次“演习”——主动触发一次 panic验证 vmcore 能被正确抓取。注意这会导致一次真实的重启必须在业务低峰且确认服务可以中断时进行。# 主动触发内核 panic会重启系统慎用 echo c /proc/sysrq-trigger # 重启后检查是否有 vmcore 生成 ls -lh /var/crash/*/vmcore拿到 vmcore 之后用crash工具做回溯。需要准备与当前内核版本完全匹配、带调试符号的vmlinux文件发行版源里通常有对应的kernel-debuginfo包。# 进入 crash 交互环境 crash /usr/lib/debug/lib/modules/$(uname -r)/vmlinux /var/crash/127.0.0.1-2024-*/vmcore # 查看内核日志 log # 查看 panic 时的调用栈 bt # 查看各 CPU 状态 foreach bt # 退出 quitbt输出的调用栈会直接指向触发 panic 的内核函数再结合log里的最后几行输出基本能定位是驱动问题、内存问题还是文件系统问题。这套流程熟练之后一次死机的根因分析可以控制在 30 分钟以内。我自己的习惯是每台新服务器上线前固定做三件事开启 sysrq、配置日志持久化、部署 kdump 并做一次主动 panic 演习。这三件事加起来不到一小时但能保证下次死机来临时你手里有完整的现场资料。内核死机这种事指望“不发生”不如准备“发生后能查清楚”。希望你下次遇到死机不用再盲猜重启键希望这套方法帮到你。本文还有配套的精品资源点击获取