who -b 是唯一能准确定位重启时间的起点，直接读取内核启动时间戳，输出如 system boot 2026-07-08 14:22，不受日志轮转、权限或 systemd 配置影响，是所有后续排查的时间基准。
who -b 是唯一能准确定位重启时间的起点
别跳过这步——所有后续排查都依赖这个时间点。who -b 直接读取内核启动时间戳，不受日志轮转、权限限制或 systemd 配置影响。输出如 system boot 2026-07-08 14:22，这就是你必须锚定的时间基准。
其他命令不可靠：last reboot -n 1 依赖 /var/log/wtmp，普通用户常无权读；uptime 只能估算，误差可能达数分钟；journalctl -b 默认查当前启动，不是“最后一次”。
- 执行
who -b后，立刻记下那个时间，后面所有journalctl和dmesg查询都要围绕它对齐 - 如果输出为空或报错，说明系统可能没正常完成上次启动（比如卡在 initramfs），这时要优先看
dmesg -T | head -n 50
journalctl -b -1 是查 systemd 层崩溃线索的核心
journalctl -b -1 查的是上一次完整启动的日志流，不是当前会话。重点不是翻全量日志，而是带条件筛选：
- 先看错误级事件：
journalctl -b -1 -p err，快速定位服务崩溃、单元失败等直接诱因 - 再扫关键词：
journalctl -b -1 | grep -i "shutting down\|reboot\|panic\|oom\|watchdog"，覆盖常见关机路径 - 如果怀疑是负载突增导致，用
--since "2026-07-08 14:15:00"截取重启前 5–10 分钟，避免被无关日志淹没
注意：journalctl 默认只保留近期日志，若 -b -1 返回空，说明日志已被轮转或配置为内存存储，必须转向 /var/log/messages 或 dmesg。
dmesg -T 是揪出 OOM 和硬件故障的最后防线
systemd 日志经常只记录“正在关机”，真正死因藏在内核环缓冲区里。重启后立即执行 dmesg -T，否则缓冲区可能被新日志覆盖。
- 找内存耗尽证据：
dmesg -T | grep -i "killed process"，输出里会带进程名和 PID，这是 OOM Killer 触发的铁证 - 查硬件异常：
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 不受 journalctl 配置影响，但缓冲区大小有限，重启后越早执行越可靠。
/var/log/messages 或 /var/log/syslog 是交叉验证的关键备份
systemd 日志可能被清理，而 /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu）更持久，适合补漏。
- 先定位关机起点：
grep -B2 -A3 "shutting down" /var/log/messages，前后几行常暴露服务僵死、磁盘 I/O hang 等前兆 - 批量扫描典型诱因：
grep -i "out of memory\|kernel panic\|power\|watchdog" /var/log/messages - 如果日志里只有
system boot没有shutting down，大概率是硬重启（断电、内核 panic 未记录完就掉电）
真正难的不是命令本身，而是把 who -b 的时间、journalctl -b -1 里的服务错误、dmesg 中的硬件警告、/var/log/messages 里的关机前行为，拼成一条逻辑链——比如 “OOM Killer 杀掉 MySQL → mysqld 退出触发 watchdog timeout → systemd 执行 reboot”。漏掉任意一环，结论就可能是错的。
