Linux查看系统启动时间及运行时间 uptime命令详解

Linux系统启动时间：三种可靠查询方法与一个常见误区

在排查故障、分析性能或者单纯想知道服务器“活了多久”时，系统启动时间是个关键信息。但你知道吗？不同命令给出的结果，背后代表的意义可能截然不同。直接说结论：追求最快，用 uptime -s；追求最可靠，用 who -b；而默认的 uptime 命令，其实只告诉你运行了多久，不包含具体的启动日期。

最可靠的是 who -b，输出 system boot YYYY-MM-DD HH:MM，精度到分钟，兼容性好；uptime -s 最快但仅新系统支持；/proc/uptime 配合 date 可脚本化推算，但需注意时区与时间校正影响。

uptime -s：最直接，但有系统版本门槛

如果你的系统比较新（比如 Ubuntu 20.04、CentOS 8 或者 Debian 11 之后的版本），那么 uptime -s 无疑是最省心的选择。敲下命令，它直接返回一个完整的启动时间戳：

uptime -s

输出格式类似 2026-04-05 08:23:17，一目了然。不过，这个方法有个硬伤：老系统不认这个选项。在一些旧的发行版（比如经典的 CentOS 6）或者极度精简的嵌入式环境里，你可能会看到 uptime: invalid option -- 's' 这样的报错。这时候，它没法自动回退到其他方法，你得手动换条路走。

这里有个常见的操作误区：看到 uptime 输出里写着 up 6 days, 12:45，就手动去推算具体的启动日期和时间。这种做法在跨越多天，或者系统经历过时区调整、夏令时甚至时间跳变时，很容易产生误差，并不靠谱。

who -b：轻量且兼容性广的“老将”

当 uptime -s 行不通时，who -b 往往是更稳妥的选择。这个命令读取的是 /var/run/utmp 文件，这个文件由内核在启动流程完成时写入，可以把它理解为系统启动时盖下的一个“时间戳”。

who -b

它的输出格式非常固定：system boot YYYY-MM-DD HH:MM，精确到分钟。最大的优点在于，它几乎不依赖用户空间的时间服务（比如 systemd-timesyncd 或 ntpd），因此受后期时间调整的影响较小，而且通常不需要 root 权限就能执行。

当然，它也有自己的适用边界：

• 如果命令输出为空，或者报错 cannot open /var/run/utmp，那通常意味着 utmp 文件损坏了，或者被有意清理过——这在一些追求极简的容器镜像或无状态系统中可能发生。
• 这个时间点记录的是 init 进程启动完成的时刻，比内核真正启动要晚几十毫秒，但对于绝大多数运维场景来说，这个精度已经足够了。
• 在一些没有 utmp 支持的最小化系统（比如某些 Alpine Linux 容器）里，这个命令会失效，这时就得考虑下一种方案。

/proc/uptime + date：脚本编写的首选，但细节决定成败

对于需要嵌入脚本、实现自动化查询的场景，/proc/uptime 配合 date 命令是经典组合。/proc/uptime 文件的第一列记录了系统自启动以来经过的秒数（浮点数，包含小数），这是内核维护的最原始、最精确的计时源。

awk '{print int($1)}' /proc/uptime

要用它反推启动时间，核心思路是用当前时间戳减去运行时长。一个推荐的写法是：

date -d "@$(($(date +%s) - $(awk '{print int($1)}' /proc/uptime)))" "+%Y-%m-%d %H:%M:%S"

这个方法虽然强大，但有几个“坑”需要留意：

• 命令中的 $(date +%s) 获取的是本地时区对应的 Unix 时间戳，而 /proc/uptime 是纯粹的秒数，因此最终结果会自动适配本地时区，一般无需额外进行 UTC 转换。
• 要避免一种看似聪明的写法：date -d "$(cat /proc/uptime | awk '{print $1}') seconds ago"。直接把浮点秒数传给 date 命令解析，当小数部分不为零时，很可能引发解析错误。
• 这个方法的前提是系统时间在启动后没有被大幅度手动校正过。如果期间执行过 date -s 或 timedatectl set-time 这类操作，推算结果就会出现偏差。

小心误区：systemctl status 显示的时间，并非内核启动时刻

在使用了 systemd 的系统上，执行 systemctl status 后，你会在开头看到一行 Since:：

Since: Sat 2026-04-05 08:23:42 CST; 6 days ago

这个时间看起来很直观，但它记录的是“用户空间初始化完成、第一个服务启动的时刻”，其数据来自 systemd 的 UserspaceTimestamp。通常，这比内核启动完成要晚 1 到 3 秒。

所以，在依赖这个信息时得明白：

• 它只在 systemd 系统中存在，对于使用 SysVinit 或 OpenRC 的发行版无效。
• 如果 systemd 启动失败并进入了救援模式（rescue mode），那么 Since: 显示的很可能是救援模式的启动时间，而非真正的正常开机时间。
• 它的输出格式受系统语言环境（locale）影响。在中文系统里，你用 grep "Since:" 可能抓不到这行，因为它显示的是“自：”。更稳妥的获取方式是：systemctl show --property=UserspaceTimestamp --value。

说到底，这里涉及三个有细微差别的时间点：内核启动完成、init 进程开始运行、用户空间服务准备就绪。它们之间存在着毫秒到秒级的间隔。对于日常运维中“机器什么时候开的”这类问题，who -b 给出的答案已经足够可靠。只有当需要进行深度的性能剖析或故障定界时，才有必要去仔细区分这三者的差异。