last reboot仅记录主动发起的重启，无法反映内核panic、断电重启、云平台热迁移等异常情况；journalctl --list-boots才是反映完整启动生命周期的权威来源。
last reboot 是最直接的命令，但它只记录“主动发起的重启”，不保证是“正常”重启。
很多运维同学查完 last reboot 就以为搞定了，结果发现内核 panic 后自动重启、电源断电恢复、云平台热迁移这些情况根本没出现在输出里——因为它们没走传统 reboot 流程，/var/log/wtmp 不写入。
为什么 last reboot 不能代表“上一次正常重启”
last reboot 读的是 /var/log/wtmp 中标记为 reboot 的条目，本质是用户或脚本调用 reboot、shutdown -r 或 systemctl reboot 后触发的记录。它对以下情况完全沉默：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 内核 panic 后触发的自动重启（日志里可能只有
Kernel panic - not syncing） - 硬电源中断后系统加电自启（BIOS 层启动，绕过 init）
- KVM/QEMU 或 AWS EC2 热迁移后的“伪重启”（
systemd可能不写wtmp） - 容器宿主机重启但容器进程被 checkpoint/restore（无传统 reboot 行为）
journalctl --list-boots 才是真正反映“启动生命周期”的权威来源
只要系统用 systemd（Ubuntu 16.04+、CentOS 7+、Debian 8+ 等），journalctl --list-boots 就是最可靠的启动时间列表。它不依赖 wtmp，而是从 journal 日志中提取每次 boot ID 对应的完整生命周期：
- 每行格式如：
-1 2026-09-15 08:22:11 UTC—2026-09-18 14:30:44 UTC - 负数序号表示历史启动：
-1是上一次，0是当前 - 时间范围即该次启动的起止（精度到秒），哪怕中间发生 panic 或 watchdog 复位，只要 systemd 成功初始化过，就会有记录
- 如果某次启动没走到 login prompt 就卡死，journal 可能没落盘，但只要进了 userspace，基本都能捕获
如何判断某次重启是不是“正常”的
单看时间不够，“正常”得结合上下文。关键不是命令本身，而是你查哪段日志、比对哪些信号：
- 先用
who -b拿到当前启动的精确起始时间（比如system boot 2026-09-18 14:30），这是所有分析的时间锚点 - 再跑
journalctl -b -1 | grep -E "(shutting down|reboot|Started.*target)"：如果末尾是Started default target且没报错，大概率是干净重启；如果开头就出现Kernel panic或Watchdog detected hard lockup，那就不是“正常” - 检查
dmesg -T | tail -n 20：重启后立刻执行，看最后几行有没有Restarting system（软重启）或Machine restart（硬件级复位）——后者往往意味着异常 - 对比
last reboot和journalctl --list-boots的时间是否一致：如果不一致，说明有未记录的重启，需重点排查硬件或内核层
真正容易被忽略的点是：UTC 和本地时区混用。journalctl --list-boots 默认 UTC，last reboot 和 who -b 是本地时区。跨时区比对前务必统一，否则你会以为“重启时间差了 8 小时”，其实只是时区没换算。
