要查看最近一次系统崩溃日志，需先确认journal持久化已启用（检查/var/log/journal/或Storage=persistent），再用journalctl --list-boots定位倒数第二次启动（-b -2），结合grep筛选panic、oops、watchdog等关键词及error级别日志分析。
Linux 没有“蓝屏”概念，但内核 panic、oops、watchdog timeout 或硬重启等现象效果类似。诊断关键不是找一张截图，而是回溯崩溃前最后几秒的内核与 systemd 行为痕迹——journalctl 是最直接的入口，前提是日志已持久化。
确认日志是否保存了崩溃现场
默认 journal 日志存在内存（/run/log/journal/），断电或 panic 后即丢失。必须先验证持久化是否生效：
- 运行 journalctl --disk-usage：若显示 0B 或 No journal files were found，说明无有效日志可查
- 检查目录：ls /var/log/journal/：应看到一个以机器 ID 命名的子目录；若为空，需执行 sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald
- 确认配置：grep "^Storage=" /etc/systemd/journald.conf，输出应为 Storage=persistent
定位崩溃发生的那次启动
崩溃通常发生在某次启动中途，而非当前会话。要用 --list-boots 找出“倒数第二次”启动（即崩溃前那次）：
- 运行 journalctl --list-boots，输出类似：
-2 abc1 Wed 2026-09-24 08:12:05 CST — Wed 2026-09-24 08:15:33 CST
-1 def2 Wed 2026-09-24 08:16:10 CST — Fri 2026-09-25 16:00:22 CST
其中 -2 就是崩溃前那次启动 - 快速验证：运行 journalctl -b -2 --no-pager | tail -n 30，看末尾是否有 abrupt 中断、无 Shutting down、无 Reached target Final Step 等非正常终止迹象
聚焦内核级崩溃线索
真正致命的崩溃大多源于内核，相关日志集中在 -k（kernel）通道，且常在末尾爆发：
- 倒序查看内核日志：journalctl -b -2 -k -r | head -n 50，重点扫视顶部（即崩溃前最后时刻）是否出现：
Kernel panic、Oops、WARNING: CPU: 、Call Trace、watchdog: BUG、Machine check events - 精准搜索关键词：journalctl -b -2 -k | grep -i -E "(panic|oops|nmi|watchdog|machine.check|EDAC|mce)"
- 补查 dmesg 缓冲区：dmesg -T | tail -n 40，尤其当 journal 持久化未启用时，这里可能保留 journal 中缺失的 panic 快照
交叉验证 systemd 层面异常
有些崩溃不触发 kernel panic，但 systemd 卡死、服务异常退出或 OOM killer 干预也会导致静默重启：
- 查 OOM 杀手记录：journalctl -b -2 | grep -i "killed process" 或 journalctl -b -2 -p 3 | grep -i "out of memory"
- 看服务最后状态：journalctl -b -2 | grep -E "(Starting|Started|Stopping|Stopped).*\.service" | tail -n 30，观察是否有服务长时间卡在 Starting 或突然中断
- 检查系统目标完成情况：journalctl -b -2 | grep "Reached target.*final"，缺失该行是硬崩溃的强信号
