uptime默认可用，但易误读；/proc/uptime更稳定，推荐用于脚本获取秒数；容器内需用inspect查StartedAt，不可依赖uptime或/proc/uptime。
uptime 不需要安装——它是 procps-ng 套件的一部分，所有主流 Linux 发行版（Ubuntu、CentOS、Debian、Alpine 等）默认自带。只要系统能跑 shell，uptime 就可用。
为什么直接运行 uptime 有时看不出是否重启过
默认输出如 08:38:12 up 2 days, 5:47, 1 user, load average: 0.03, 0.05, 0.02，其中 up 2 days, 5:47 是关键，但容易被误读为“当前时间”或忽略单位歧义（比如 3:47 是小时:分钟，不是时间点）。更麻烦的是：
- 不同 locale 下单位缩写不一致（中文系统显示“天”，英文可能显示“days”，某些嵌入式系统甚至省略单位）
- 容器内执行时，它显示的是宿主机 uptime，而非容器本身启动时长
- 刚硬重启后可能显示
up 0 min或up 1 min，但若系统卡在 initramfs 阶段，uptime仍会从内核启动起计，导致“看似正常实则异常”
脚本中安全提取运行秒数：优先读 /proc/uptime
比 uptime 更底层、更稳定，不受 locale、终端宽度或发行版差异影响。第一列是总运行秒数（浮点），精度到百毫秒：
awk '{print int($1)}' /proc/uptime这个命令返回纯整数秒，适合做数值比对。注意以下几点：
- 某些低权限容器或 WSL1 环境下，
/proc/uptime可能报Permission denied，此时 fallback 到uptime -s+date +%s手动计算 - 不要用
shell内置的$SECONDS或time.time()做差值——它们依赖进程生命周期，无法反映系统级 uptime - 如果要转成易读格式，用
awk计算时注意小数截断：awk '{printf "%d天 %d小时 %d分钟\n", int($1/86400), int($1%86400/3600), int($1%3600/60)}' /proc/uptime
检测非预期重启：别只看单次 uptime 值
单次运行 uptime 只能告诉你“现在跑了多久”，无法判断“是否中途断过”。真正有效的审计必须跨时间点比对：
- 每日固定时刻（如
03:00）用 cron 记录：echo "$(date -Iseconds) $(awk '{print int($1)}' /proc/uptime)" >> /var/log/uptime.log - 比对相邻两行第二列差值：若
curr - prev < 3600，基本可判定发生过重启（排除计划内维护） - 立刻关联
last reboot | head -3和journalctl -b -1 --since "1 hour ago" | grep -E "(started|crash|panic|oom)"锁定原因 - 特别注意
dmesg -T | head -1输出的时间戳——它才是内核真正启动时刻，比systemctl show --property=UserspaceTimestamp更可信
最常被忽略的一点：uptime 在容器里永远显示宿主机时间，而 /proc/uptime 在 PID namespace 隔离良好的环境中（如 rootless Podman）才可能反映容器真实生命周期——但这不是标准行为，不能依赖。查容器自身存活时长，唯一可靠方式是 docker inspect 或 podman inspect 中的 StartedAt 字段。
