在Linux服务器运维与系统管理过程中,准确掌握系统的重启历史、重启原因以及运行时长是排查故障、保障业务连续性的核心技能。核心上文归纳是：查看Linux重启记录最直接的方法是使用 last 命令读取 wtmp 文件，快速确认最近一次启动时间可使用 who -b 或 uptime，而深入分析重启原因则必须依赖 journalctl（Systemd系统）或查看 /var/log/messages 中的内核与系统服务日志。 通过组合运用这些命令，管理员不仅能精确还原重启时间轴，还能有效区分是人为操作重启还是系统异常崩溃。
使用基础命令快速定位重启时间
对于运维人员而言,第一时间获取服务器启动状态往往能快速定位问题范围，Linux系统提供了几个内置的轻量级工具，能够无需繁琐参数即可输出核心时间信息。
last 命令是查看重启历史的首选工具，该命令默认会读取 /var/log/wtmp 二进制文件，该文件记录了系统的所有登录、登出和重启事件，在终端中直接执行 last reboot，系统会列出按时间倒序排列的重启记录，输出信息通常包含重启发生的日期、时间、终端（通常显示为 system boot）、内核版本以及重启持续的时间，通过观察这一列表，管理员可以清晰地看到服务器在过去的运行周期内经历了多少次重启，若需要查看更详细的关机记录，可以使用 last -x | grep shutdown，这能帮助确认系统是正常关机还是突然断电。
who -b 命令提供了最简洁的最近一次启动时间，当只需要确认服务器当前运行了多久，或者最后一次启动是什么时候，who -b 会直接输出 “system boot” 对应的时间戳，这个命令非常适合用于自动化脚本中，用于判断系统是否在特定时间窗口内发生过重启。
uptime 命令通过计算当前负载与运行时长来侧面反映重启情况，虽然它主要展示系统负载和用户数量，但其输出的 “up load time” 能够直接告诉管理员系统自上次重启以来连续运行的时间，如果发现 “up” 时间非常短，结合业务中断的时间点，即可推断出该时间点发生了重启。
深入分析系统日志挖掘重启原因
仅仅知道重启发生的时间是不够的,专业的运维人员需要通过日志分析出“为什么重启”，在现代Linux发行版（如CentOS 7/8、Ubuntu 16.04+）中，Systemd 的 journalctl 工具提供了最为权威和详细的日志分析能力。
使用 journalctl --list-boots 命令，可以列出所有启动会话的索引ID（Boot ID），这为查看特定某一次重启的日志提供了索引，若要查看上一次启动的日志，可以使用 journalctl -b -1，在日志流中，重点关注包含 “kernel”、”systemd-shutdown” 或 “acpi” 关键字的行，如果日志末尾出现了 “Kernel panic” 或 “Hardware Error” 字样，这通常意味着硬件故障或内核崩溃导致的强制重启，如果日志平滑过渡到 shutdown 流程，则多为人为操作。
对于尚未完全迁移到Systemd的传统系统,或者需要查看更底层的硬件事件，/var/log/messages 和 /var/log/dmesg 是关键文件，通过 grep 命令搜索这些文件中的特定关键字，如 “rebooting”、”restart” 或 “hardware error”，往往能发现蛛丝马迹，执行 grep -i "reboot" /var/log/messages 可以过滤出系统层面的重启指令记录，查看 /var/log/dmesg 或使用 dmesg | grep -i "hardware" 有助于发现是否因过热（Thermal trip）或电源故障导致的非正常关机。
区分正常重启与异常崩溃的专业见解
在实际生产环境中,区分人为维护重启与系统异常崩溃是排查问题的关键分水岭，人为重启通常会在日志中留下明确的命令执行记录，systemctl reboot 或 shutdown -h now 的调用痕迹，且日志记录是完整保存的，关机流程会经过 systemd-shutdown 的各个阶段。
相反,异常崩溃（如Kernel Panic、硬件故障、OOM Killer触发）往往伴随着日志的突然中断。如果在 journalctl 或 /var/log/messages 的末尾没有看到正常的关机序列，而是直接跳跃到了下一次启动的硬件探测信息，这极大概率是宕机或掉电，应重点检查 /var/log/crash 或配置了 kdump 的 crash dump 文件，独立见解在于关注日志中的 “ACPI” 或 “Watchdog” 信息，如果看到 “watchdog: watchdog did not stop”，这通常是硬件死锁导致看门狗强制复位硬件的结果，这类问题往往与驱动程序死锁或严重的硬件错误相关。
日志轮转与数据持久化策略
为了确保重启记录的可追溯性,必须关注日志轮转（logrotate）配置，默认情况下，/var/log/wtmp 和 /var/log/btmp 可能会被压缩或清理，导致久远的历史重启记录丢失，专业的建议是修改 /etc/logrotate.conf 或对应的自定义配置文件，适当增加 wtmp 和系统消息日志的保留周期（rotate count）和保留时间（monthly/weekly），对于关键业务服务器，建议配置远程日志服务器（如使用 Rsyslog 或 ELK Stack），将本地日志实时同步到远程存储，这样，即使本地服务器发生灾难性故障导致磁盘损坏或日志丢失，管理员依然可以在远程端查看到最后一刻的崩溃日志，从而实现真正的E-E-A-T（专业、权威、可信）运维闭环。
相关问答
Q1：last 命令显示的重启记录为空，或者时间不正确，可能是什么原因？
A1： 这种情况通常意味着 /var/log/wtmp 文件被意外清空、删除，或者文件权限损坏导致系统无法写入登录/重启记录，首先应检查该文件是否存在（ls -l /var/log/wtmp），如果文件丢失，可以尝试通过 touch /var/log/wtmp 命令创建空文件，但这只能恢复未来的记录，系统时间未同步（NTP配置错误）也会导致记录的时间戳不准确，此时应优先检查 /var/log/messages 或 journalctl 中的系统日志作为替代数据源。
Q2：如何查看Linux系统是否因内存不足（OOM）而触发了重启？
A2： OOM（Out Of Memory） Killer 通常会杀掉进程来释放内存，但在极端情况下可能导致系统不稳定或重启，要确认这一点，可以使用 dmesg | grep -i "out of memory" 或 journalctl -k | grep -i "kill process"，如果看到了 “Out of memory: Kill process” 的记录，说明系统曾发生过内存耗尽，虽然OOM Killer本身不直接重启服务器，但若系统关键进程（如Init）被杀，将导致系统崩溃重启，此时应结合 last 命令的时间点，查看该时间点前后的内存使用情况。
互动
如果您在查看Linux重启记录的过程中遇到过特殊的日志报错,或者有更高效的排查技巧，欢迎在评论区分享您的实战经验，我们可以共同探讨更深入的系统故障诊断方案。
