关键是从重启瞬间锁定日志上下文，先验证journal持久化是否启用（journalctl --disk-usage及ls /var/log/journal/），再用-b -1查看上一次启动完整快照，结合-k筛选内核异常、-u追踪服务恢复、-r倒序定位中断点，交叉验证崩溃前兆与恢复行为。

要监控系统异常重启后的恢复过程日志，关键不是等“恢复完成”再查，而是从重启发生的那一刻起，就锁定日志上下文——包括崩溃前兆、关机中断痕迹、以及本次启动中服务逐个拉起的真实行为。

确认日志是否保留了上一次崩溃现场

systemd-journald 默认将日志存于内存（/run/log/journal/），断电或内核 panic 会导致这部分日志丢失。必须先验证持久化是否启用：

• 运行 journalctl --disk-usage：若显示为 0B 或提示“No journal files”，说明日志未落盘
• 检查 ls /var/log/journal/：应存在一个以机器 ID 命名的子目录；若无，执行 sudo mkdir -p /var/log/journal && sudo systemctl restart systemd-journald

定位上次启动中异常终止的证据链

启用持久化后，-b -1 才有意义。这不是“崩溃日志命令”，而是整个上一次启动周期的完整快照，重点看末尾是否自然收尾：

• 倒序查看最后 100 行：journalctl -b -1 -n 100 -r，观察是否有 abrupt stop、无 shutdown 记录、或突然中断
• 搜索正常关机标志：journalctl -b -1 | grep "Reached target.*final"，缺失即暗示硬重启或 panic
• 筛查 systemd 调度失败：journalctl -b -1 | grep -E "(Failed|Timed out|killed|aborted)"，尤其关注 systemd-shutdown 或 kernel 相关行

跟踪本次启动中服务恢复的实际执行流

异常重启后，系统会尝试重新拉起所有 enabled 的服务，但未必全部成功。需结合时间与单元维度观察真实恢复节奏：

• 实时盯住关键服务：journalctl -f -u sshd.service -u nginx.service --since "10 seconds ago"
• 对比依赖状态：journalctl -b | grep -E "(network.target|local-fs.target|multi-user.target)"，确认基础目标是否就绪
• 查某服务启动全过程：journalctl -b -u myapp.service --all（加 --all 显示所有优先级，含 debug 级输出）

聚焦内核层是否残留故障影响

很多“恢复失败”实为硬件或驱动问题延续，需单独提取内核日志交叉验证：

• 只看本次启动的内核消息：journalctl -b -k
• 快速扫视末尾异常：journalctl -b -k -r | head -30，找 Kernel panic、Oops、Call Trace
• 查硬件错误线索：journalctl -b -k | grep -i -E "(mce|EDAC|nvme.*error|ata.*timeout)"