最准的系统启动时间查法是 uptime -s，它直接读取内核启动时间戳，输出如 2026-01-19 08:47:12，不受负载干扰，适合监控脚本；who -b 读 utmp，精度到分钟，用于审计；last reboot 查 wtmp 历史，需注意 still running 状态；/proc/uptime 最底层但需换算，休眠不计时。
uptime -s 直接输出精确启动时间戳
系统开机时间最准、最省事的查法就是 uptime -s，它直接从内核读取启动时刻，不依赖日志文件或服务状态，只要系统没崩溃过，这个时间就可信。
- 执行
uptime -s，输出类似2026-01-19 08:47:12，这就是系统真正开始运行内核的时间点 - 和
uptime基础命令不同，-s不受负载、用户数等干扰，纯返回时间，适合写监控脚本 - 注意：如果系统启用了 NTP 时间同步，且在启动后大幅校正过时间，
uptime -s的值仍以本地时钟为准，不会回溯修正——它记录的是“当时认为的那一刻”，不是 UTC 绝对时间
who -b 是审计级可信来源
who -b 读的是 /var/run/utmp，这个文件由 init 进程在系统初始化完成瞬间写入，是 Linux 系统中最早落盘的启动标记之一，比 systemd 或 syslog 都早，常被用于安全审计。
- 输出格式固定为
system boot YYYY-MM-DD HH:MM，没有秒级精度，但足够定位到分钟级事件 - 如果系统重启后
utmp被清空（比如某些容器环境或异常关机），who -b可能报错或无输出，这时要 fallback 到其他方法 - 它不显示时区缩写，但默认按系统本地时区解析，和
uptime -s一致；若需强制 UTC，得靠date -u -d "$(who -b | awk '{print $3,$4}')" +'%Y-%m-%d %H:%M:%S'这类组合
last reboot 查历史，但要注意 still running 的陷阱
last reboot 从 /var/log/wtmp 读取所有重启记录，适合排查是否发生过意外重启，但它有个关键细节容易误读：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 最新一条记录末尾若显示
still running，说明该次启动至今未结束，时间可信；但如果看到crash或时间范围如(02:15)，代表那次启动已终止，当前会话是之后另一次启动 -
wtmp文件可能被轮转或清理（尤其在低配 VPS 上），last reboot可能只保留最近几次，不能默认看到的就是“第一次”启动 - 想快速取最近一次时间，用
last reboot | head -1即可，但别忘了检查末尾字段——有时head -1拿到的是旧记录，因为last默认倒序，而部分发行版日志轮转逻辑会让新条目插在中间
/proc/uptime 需手动换算，但最底层、最稳定
/proc/uptime 第一列是自启动以来的总秒数（含小数），它是内核实时维护的计数器，不依赖任何用户空间服务，哪怕 systemd 挂了也能读到。
- 用
awk '{print int($1)}' /proc/uptime提取整秒数，再喂给date -d "@$SECONDS"才能得到启动时间，例如：date -d "@$(awk '{print int($1)}' /proc/uptime)" +"%Y-%m-%d %H:%M:%S" - 小数部分（如
432567.89中的.89）是当前秒内的 jiffies，一般忽略即可；强行保留会导致date解析失败 - 这个方法在嵌入式或最小化系统里特别有用，但要注意：如果系统休眠过，
/proc/uptime不会计入休眠时间——它只统计 CPU 实际运行时间，所以推算出的“开机时间”可能比真实通电时间晚
真正难判断的不是怎么查，而是当几个命令结果不一致时信谁。比如 uptime -s 和 who -b 差几分钟，大概率是系统启动过程中时钟被 NTP 或硬件 RTC 校正过；而 last reboot 显示的时间明显更早，那多半是 wtmp 日志残留。这时候得看场景：运维巡检信 who -b，故障复盘盯 last reboot，自动化脚本优先用 uptime -s。
