最可靠的方法是读取/proc/uptime获取秒数，日常查看用uptime -p，精确开机时刻优先who -b（分钟级、底层稳定），其次uptime -s（秒级、依赖systemd）；避免使用top、systemctl show、last reboot等易误导的命令。
直接用 uptime 就能看到开机时长，但要注意它默认输出包含当前时间、负载等干扰信息；真正只关心“开了多久”，优先用 uptime -p 或 uptime -s 配合计算。
uptime -p：最简洁的人类可读时长
它把系统已运行时间直接转成“X天Y小时Z分钟”格式，不带多余字段，适合快速确认、脚本提示或监控告警文案。
-
uptime -p输出示例：up 3 weeks, 2 days, 5 hours, 12 minutes - 比
uptime默认输出干净得多，避免误把当前时间（如22:08:15）当成开机时间 - 所有主流发行版都支持，包括 CentOS、Ubuntu、Debian、UOS、麒麟等
- 不显示秒级精度——如果需要精确到秒，得换方法
uptime -s vs who -b：哪个更可信？
uptime -s 和 who -b 都输出开机时刻，但来源不同、精度不同、适用场景也不同。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
uptime -s输出类似2026-09-04 10:22:33，是本地时区时间，精度到秒，但依赖 systemd 或 init 系统的时间同步逻辑 -
who -b输出类似system boot 2026-09-04 10:22，精度只到分钟，但直接读/var/run/utmp，几乎不受用户空间延迟影响，更底层、更轻量 - 在 WSL、嵌入式 Linux 或 systemd 启动异常时，
who -b往往还能用，而systemctl status可能报错或为空 - 如果
who -b输出为空，说明utmp损坏或权限不足，此时应 fallback 到uptime -s
/proc/uptime：脚本里算开机时长的唯一可靠源
这个文件第一列是浮点数，表示系统自启动以来的总秒数（含小数），是内核直接维护的原始值，没任何中间层解析或格式化。
- 执行
cat /proc/uptime得到类似214567.89 123456.78，取第一个数即可 - 脚本中别直接用浮点运算，先
awk '{print int($1)}'截断小数，避免 shell 整数运算出错 - 要反推开机时间戳，用：
date -d "@$(($(date +%s) - $(awk '{print int($1)}' /proc/uptime)))" - 在容器或 SELinux 严格策略下可能报
Permission denied，需提前加test -r /proc/uptime判断
别踩这些坑
很多看似合理的命令其实容易误导，尤其在排查异常重启或写自动化脚本时。
- 别用
top输出里的up X min做判断——它和uptime一样，但界面刷新会掩盖历史变化，不适合日志留存 - 别信
systemctl show --property=UserspaceTimestamp，它经常为空，且只代表用户空间就绪时间，比内核启动晚几秒 -
last reboot查的是 wtmp 日志，不是实时状态；如果系统没正常关机（比如断电），这条记录可能缺失或不准 - 容器里跑
uptime -s显示的是容器启动时间，不是宿主机——别查完就去重启物理机
真正要写监控脚本或做故障复盘，/proc/uptime 是唯一值得信任的秒级源；日常看一眼，uptime -p 最省事；要确认是否刚重启过，who -b 的分钟级精度反而更稳——它不依赖任何服务，只靠内核写的一行 utmp 记录。
