想看Linux服务器的启动时间,打开终端执行 who -b 就能拿到结果。这条命令会直接返回系统上次开机的时间点,格式为“系统启动 日期 时间”,如果你连重启历史也想一并看清,再配合 last reboot 即可,下面我从命令细节到实际排查场景,把这件事拆开讲清楚。
linux查看服务器启动时间:先用这三个命令摸清底细
在动手之前,先明确一个概念:启动时间指的是内核完成加载、系统开始运行那一刻的时间戳,Linux 下能查这个时间点的命令不少,日常运维最常用的是下面三个,它们各有侧重,适用场景也不同。
who -b:最简单直接的查询命令
who -b 是查看系统启动时间的首选命令,参数 -b 表示 boot,也就是系统引导时间。
执行后输出类似这样:
system boot 2026-03-18 09:23
关键点是这个时间:它来自内核记录的系统启动时刻,不受你手动修改系统时间的影响,因为内核在启动瞬间就把这个时间写进了内存,哪怕你后来用 date 改过系统时钟,这个值也不会变,所以当你怀疑服务器时间被调过时,who -b 的结果反而是最可靠的参考。
这个命令在大多数发行版上默认可用,无需额外安装软件包,如果你用的是精简版容器或者极简系统,可能提示找不到命令,这时可以用 uptime -s 替代,效果一样。
uptime:用运行时长反推开机时间
uptime 大家都很熟,它显示的是系统已经运行了多久,但很多人忽略了它也能用来计算启动时间,执行 uptime -s 看到的输出是:
2026-03-18 09:23:41
这个参数 -s 表示 since,即系统自哪个时间点开始运行,和 who -b 相比,uptime -s 的精度到了秒,适合需要精确记录的场合。
如果你只想看运行了多久,直接输 uptime 就行:
14:22:11 up 3 days, 4:59, 2 users, load average: 0.01, 0.05, 0.03
这里的 up 3 days 已经帮你算好了天数,我习惯在写巡检脚本时用 uptime -s,因为它是标准输出,用 awk 切字段很方便。
last reboot:把重启历史翻个底朝天
last reboot 读取的是 /var/log/wtmp 日志文件,它会列出每一次系统重启的准确时间,从最近一次往前排,输出类似:
reboot system boot 2026-03-18 09:23 still running
reboot system boot 2026-03-15 22:47 still running
reboot system boot 2026-03-10 08:12 still running

每行代表一次开机记录,最上面一条永远对应当前的启动事件,这个命令的价值在于历史回溯如果服务器被人重启过,你想知道之前的重启频率,用 last reboot | head -20 就能拉出最近二十次记录。
| 命令 | 查询范围 | 精度 | |
|---|---|---|---|
| who -b | 最近一次启动时间 | 仅当前状态 | 分钟级 |
| uptime -s | 最近一次启动时间 | 仅当前状态 | 秒级 |
| last reboot | 历次完整重启记录 | 历史全部(取决于wtmp保留策略) | 分钟级 |
三条命令各有用途:只想知道“什么时候开机的”选 who -b;做自动化脚本抓取时间戳用 uptime -s;排查历史重启问题时 last reboot 才是正主。
linux重启历史记录怎么查:从日志里还原每一次开机
很多运维朋友遇到的问题是:服务器莫名重启了,但自己不知道是什么时候发生的,这时候 who -b 只能告诉你“现在它重启过”,给不出历史脉络,必须借助 last reboot 来看完整记录。
如何读懂 last reboot 的输出
last reboot 的输出每一列都有含义,第一列 reboot 固定不变,表示记录类型;第二列 system boot 说明是系统引导;紧接着的日期时间是启动时刻;末尾的 still running 表示该次启动一直运行到现在,如果是历史记录,末尾会变成 down 加一个时间,那是系统最后关机的时间点。
举个例子:
reboot system boot 2026-03-15 22:47 down 2026-03-18 09:20
这一行表示系统在3月15日22点47分启动,3月18日9点20分关闭,期间运行了两天多,最后一条 down 和 still running 的差别,正好告诉你上次关机到这次开机之间的间隔。
wtmp 文件轮转带来的限制
这里必须提醒一句:last reboot 能查多远,取决于 /var/log/wtmp 文件是否被轮转清理,多数发行版默认用 logrotate 每周或每月轮转一次 wtmp,也就是说你能看到的记录一般是最近几周到一两个月,行业共识认为,超过三个月前的重启记录大概率查不到,除非你配置了日志集中存储,如果你想知道服务器装了多久、最早一次开机是什么时候,last reboot | tail -1 的结果仅供参考,不能当成绝对证据。
结合系统日志验证重启原因
光知道“什么时候重启”不够,还得知道“为什么重启”,查启动时间后,紧接着可以翻

journalctl --list-boots 查看历次开机对应的日志编号,再用 journalctl -b -1 查看上一次启动的内核日志,这个组合是排查重启原因的经典路径:先确认时间点,再定位时间点前后的内核报错、硬件异常或 OOM 记录。
更精确的启动时间:深入系统内部找答案
who -b 的精度到分钟,大多数场景够用,但如果你要写运维报告,或者需要精确到秒的启动时刻,就得换工具。
systemd-analyze:查看启动过程耗时分布
现在主流发行版都使用 systemd 作为初始化系统,systemd-analyze 这个命令可以查看启动过程花了多久:
Startup finished in 2.847s (kernel) + 8.921s (initrd) + 15.302s (userspace) = 27.070s
graphical.target reached after 15.299s in userspace
输出会告诉你内核阶段、initrd 阶段和用户空间阶段各耗时多少,虽然它不直接显示“启动时间点”,但结合 uptime -s 拿到的时间戳,减去总耗时,就能推算出硬件加电到内核加载完成的完整时间线,这个方法在性能调优时很实用,比如你想知道是不是某个 systemd 服务拖慢了开机速度,执行 systemd-analyze blame 就能按耗时给服务排序。
从 /proc/uptime 算出精确到秒的启动时刻
/proc/uptime 文件记录的是系统自启动以来经过的秒数,精度高,不受时区影响,用下面这条命令可以直接得出启动时间:
date -d "$(cut -d. -f1 /proc/uptime) seconds ago"
cut -d. -f1 先取整秒数,date -d "xxx seconds ago" 反推出当前时间往前推这么多秒就是启动时间,输出是标准日期格式,比 who -b 的精度高不少,这个方法的好处是不依赖任何日志文件,纯粹基于内核计数器,任何情况下都能用。
看 /proc 目录时间戳做旁证
内核挂载 /proc 虚拟文件系统时会给根目录打一个时间戳,这个时间就等于系统启动时间,执行:
stat /proc
输出里的 Birth 字段(部分系统显示为 Change)通常就是系统启动的精确时刻,这个方法适合 who -b 不可用且没有 systemd 的极简环境,是判断启动时间的最后一招。
实际排查中的几个场景:启动时间怎么用
命令学会了,回到真实运维场景里看看这些信息怎么派上用场。
服务器突然连不上,重启后想确认宕机时间
先执行 last reboot | head -3 看最近几次启动记录,找到当前启动时间,再执行 journalctl -b -1 查看上一次启动的日志尾部,找最后一条时间戳,那就是宕机前最后活动的时刻,两次时间之差就是服务器不可用的时长。

怀疑有人手动重启过服务器
检查 last reboot 的启动时间点,如果恰好在深夜或者节假日,就很可疑,接着用 journalctl --since "2026-03-18 09:20" --until "2026-03-18 09:25" 查看这个时间窗口内有没有登录记录,能进一步确认是远程操作还是物理重启。
虚拟化环境里启动时间对不上
虚拟机迁移(如 VMware vMotion 或 KVM 热迁移)会保留运行状态,迁移后 uptime 显示的运行时长会超级长,甚至超过宿主机运行时间,此时要判断虚拟机真实启动时间,用 who -b 也不靠谱,因为某些虚拟化平台会同步宿主机的时钟,更可靠的方法是看 dmesg | grep "Linux version",内核打印的时间戳([ 0.000000])对应的系统时间才是真实启动点,换算公式是当前时间减去该时间戳数值,业内专家指出,这种情况在云服务器里相当常见,遇到时优先参考 dmesg 而不是 wtmp。
批量查询多台服务器的启动时间
写个循环脚本逐个执行 uptime -s,把输出重定向到文件,再统一分析,因为 uptime -s 的输出格式固定(YYYY-MM-DD HH:MM:SS),排序、对比都很方便,先挑出启动时间最早的那台,可能就是物理机本身,其他时间相近的则是同期批量部署的机器。
关于Linux服务器启动时间查询的常见问题
Q1:为什么 who -b 和 last reboot 显示的时间不一样?
who -b 读的是内核维护的启动时间变量,last reboot 读的是 wtmp 日志中记录的开机事件,两者一般是一致的,但如果 wtmp 日志被清理过,或者系统时间在启动后被大幅调整过,就会出现偏差,碰到这种情况,以 who -b 为准,更可靠的是通过 /proc/uptime 反推。
Q2:服务器一直运行没有重启过,启动时间应该怎么理解?
启动时间反映的是内核初始化的时刻,对应的是这台机器当前这个“运行会话”的起点,只要系统没有重启,这个时间就一直不变,哪怕是虚拟机迁移或网络断开重连,都不会影响它。
Q3:时间戳显示是几个月前,但服务器状态明显像是刚开机,可能吗?
可能,虚拟化环境挂起恢复、休眠唤醒、时钟漂移校正等操作都会导致系统时间跳变,从而让 who -b 的结果失真,如果怀疑,优先看 dmesg 内核日志第一条的时间戳,再对比 uptime 显示的运行时长做交叉验证,就能判断哪个时间才是真实可信的。
图片来源于AI模型,如侵权请联系管理员。作者:酷小编,如若转载,请注明出处:https://www.kufanyun.com/ask/786558.html


评论列表(1条)
读了这篇文章,我深有感触。作者对执行的理解非常深刻,论述也很有逻辑性。内容既有理论深度,又有实践指导意义,确实是一篇值得细细品味的好文章。希望作者能继续创作更多优秀的作品!