who -b 命令用于显示系统最后一次启动的精确时间戳，输出格式为“system boot yyyy-mm-dd hh:mm”，数据直接读取自 /var/run/utmp，权威可靠，是排查重启事件的基准起点。
who -b 是唯一能锚定重启时间的起点
所有后续排查都依赖这个时间点。执行 who -b，输出如 system boot 2026-09-20 03:17，这就是内核实际启动时间戳，不受日志轮转、权限或 systemd 配置影响。别跳过这步——如果输出为空或报错，说明上次启动没完成（比如卡在 initramfs），此时要立刻转向 dmesg -T | head -n 50 看早期内核状态。
journalctl -b -1 -p err 只查错误级线索
它不是翻全量日志，而是聚焦上一次完整启动中明确标记为 error 的事件。常见有效组合：
-
journalctl -b -1 -p err：快速定位服务单元失败、依赖崩溃、timeout 等直接诱因 -
journalctl -b -1 | grep -i "shutting down\|reboot\|panic\|oom\|watchdog"：覆盖主流关机路径关键词 -
journalctl -b -1 --since "2026-09-20 03:10:00" -u systemd-shutdown：用who -b时间往前推 5–10 分钟，避免被无关日志淹没
注意：journalctl -b -1 返回空，大概率是日志未持久化——先运行 journalctl --disk-usage，若为 0B，说明日志只存在内存里，已随重启丢失，必须转向 dmesg 和 /var/log/messages。
dmesg -T 是最后防线，但必须抢时间
内核环缓冲区内容极易被新日志覆盖，重启后越早执行越可靠。重点不是通读，而是定向扫描：
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
dmesg -T | grep -i "killed process"：OOM Killer 触发铁证，带进程名和 PID -
dmesg -T | grep -A2 -B2 "BERT\|mce\|thermal"：BERT 表示 BIOS 级 ECC 内存错误，mce 是 CPU/PCIe 硬件校验异常，thermal 是过热强制关机 -
dmesg -T | tail -n 20：确认是否真重启——末尾出现Restarting system或Machine restart才闭环
如果 dmesg -T 输出只有启动日志、无任何异常痕迹，说明内核可能在 panic 后清空了 ring buffer，此时需结合 /var/log/kern.log 或 /var/log/messages 交叉验证。
/var/log/messages 是兜底备份，别只信 journalctl
systemd 日志可能缺失，但传统 syslog 有时保留着关键现场。尤其当 journal 没启用持久化时，/var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu）反而是唯一线索源：
-
grep -i "kernel:.*error\|panic\|segfault" /var/log/messages：绕过 journalctl 的二进制解析，直扫原始内核报错 -
grep -B3 -A3 "shutting down" /var/log/messages：看 shutdown 前 3 行、后 3 行，常有资源耗尽、磁盘 I/O hang 等上下文 -
grep "Out of memory" /var/log/messages：比 dmesg 更易匹配到 OOM 全路径日志
硬件故障或电源异常导致的“幽灵重启”，往往在 /var/log/messages 里留下 ACPI: Power Button、nvme 0000:01:00.0: PCIe Bus Error 这类线索，而 journalctl 里完全找不到对应记录。
