要定位linux系统重启原因，需通过日志线索拼出关机/崩溃前的异常行为：先验证日志是否持久化（journalctl --disk-usage、ls /var/log/journal/），再用journalctl -b -1 -r、grep“final step”及内核日志（-k）等分析异常终止痕迹。
要定位 Linux 系统重启原因，关键不是找“某一条崩溃退出记录”，而是通过日志线索拼出关机/崩溃前的异常行为。journalctl 本身不直接标记“这是崩溃退出”，但能提供足够证据链——只要日志持久化启用且未被覆盖。
确认日志是否真正保留了上次崩溃信息
默认情况下，systemd-journald 把日志存在内存（/run/log/journal），断电、内核 panic 或强制重启后，这部分日志就丢失了。所以第一步必须验证：
- 运行 journalctl --disk-usage —— 若显示 0B 或 “No journal files were found”，说明日志未持久化，-b -1 很可能为空或不可靠
- 检查目录是否存在：ls /var/log/journal/ —— 应看到一个以机器 ID 命名的子目录
- 若不存在，手动启用： sudo mkdir -p /var/log/journal sudo systemctl restart systemd-journald
查看上一次启动中异常终止的痕迹
启用持久化后，journalctl -b -1 才有意义。它不是“崩溃日志专用命令”，而是整个上一次启动周期的日志快照。重点看末尾是否有非正常关机信号：
- 倒序查最后 100 行：journalctl -b -1 -n 100 -r —— 新日志在前，更容易发现末尾突然中断、无 shutdown 记录的情况
- 搜索关机目标是否达成：journalctl -b -1 | grep "Reached target.*final" —— 正常关机应出现类似 Reached target Final Step；若没出现，大概率是硬重启或 panic
- 检查 systemd 是否报错退出：journalctl -b -1 | grep -E "(Failed|Dependency failed|Timed out|killed|aborted)" —— 特别关注 systemd-shutdown 或 kernel 相关行
聚焦内核层崩溃线索
很多重启源于内核级故障（如 panic、oops、硬件错误），这些通常出现在内核日志里：
- 只看内核日志 + 倒序：journalctl -b -1 -k -r —— 快速扫视末尾是否有 Kernel panic、Oops、WARNING、Call Trace
- 配合 dmesg 辅助验证：dmesg -T | tail -30 —— 内核环形缓冲区有时残留 journal 里没有的 panic 信息（尤其未启用持久化时）
- 查硬件相关错误：journalctl -b -1 -k | grep -i -E "(mce|EDAC|machine check|nvme.*error|ata.*timeout)"
补充：实时监控本次启动中的崩溃苗头
如果想提前预警、避免下次重启，可在当前系统中开启实时跟踪：
- 监控高危关键词：journalctl --this-boot -f -p 3 | grep -i -E "(panic|oops|segfault|watchdog|hardware error|killed process|out of memory)"
- 单独盯内核日志流：journalctl --this-boot -f -k | grep -i -E "(BUG:|unable to handle|Kernel panic)"
- 注意：-f 是实时滚动的关键，不加就只是静态快照
