Linux系统宕机应优先分析dmesg和/var/log/kern.log中panic、OOM、IO error等内核级信号，再用journalctl按启动编号与时间窗追溯事件链，同步排查硬件故障与kdump转储文件。
Linux系统突然宕机，日志是唯一能回溯真相的线索。关键不是“看所有日志”，而是按时间、层级和特征快速聚焦——先锁定崩溃瞬间的内核级信号，再顺藤摸瓜查关联异常。
一、优先抓取内核崩溃现场
宕机往往由内核级错误触发，/var/log/kern.log 和 dmesg 是第一响应源：
- 立即执行
sudo dmesg -T | tail -30，查看带时间戳的最近30条内核消息，重点关注含 panic、Oops、BUG、out of memory、IO error 的行 - 若系统已重启，检查
/var/log/kern.log中崩溃前最后几秒的记录：sudo grep -i "panic\|fail\|error" /var/log/kern.log | tail -15 - 注意时间断层：如果日志里突然缺失几分钟，可能说明系统在那段时间已无响应或日志服务自身挂了
二、用 journalctl 锁定崩溃时间窗
systemd 日志能串联系统服务、内核、用户进程行为，适合还原完整事件链：
- 先确认最后一次正常启动时间：
sudo journalctl --list-boots，找到宕机前那次 boot 的编号（如 -2） - 针对性查看该次启动末期的日志：
sudo journalctl -b -2 --since "2026-03-08 22:45:00" --until "2026-03-08 22:52:00"（替换为实际可疑时间段） - 过滤高危信号：
sudo journalctl -b -2 | grep -E "(emergency|alert|critical|error|panic)"
三、排查硬件与底层资源异常
很多“无故宕机”实为硬件故障或资源耗尽的表象，日志中常有隐性提示：
-
内存问题：dmesg 中出现
Hardware name: ... Memory failure或Page allocation failure，配合sudo smartctl -a /dev/sda检查磁盘 SMART 状态 -
存储故障：/var/log/messages 中反复出现
end_request: I/O error、ataX.00: failed command，说明硬盘或控制器异常 -
过热/电源不稳：dmesg 或 IPMI 日志（
ipmitool sdr）中出现Thermal event、Power supply failure
四、检查是否启用并捕获了内核转储
若配置了 kdump，/var/crash/ 下会有 vmcore 文件，这是最直接的崩溃证据：
- 确认 kdump 是否运行：
sudo systemctl status kdump - 查看是否有新转储：
ls -lt /var/crash/，找最近生成的vmcore或dump*文件 - 用 crash 工具分析（需对应内核调试符号包）：
crash /usr/lib/debug/boot/vmlinux-$(uname -r) /var/crash/vmcore，进入后输入bt查看崩溃调用栈
