1. 项目概述为什么我们需要查看Linux重启记录在日常运维、系统排障或者安全审计工作中有一个看似简单却至关重要的需求搞清楚这台Linux服务器什么时候重启过以及为什么重启。无论是半夜被报警叫醒发现服务中断还是例行检查系统稳定性亦或是调查一次可疑的系统异常查看系统的重启历史记录都是我们打开终端后要做的第一件事。这不仅仅是运行一两条命令那么简单背后关联着系统日志机制、时间管理、权限控制乃至安全基线配置等一系列知识。很多人第一反应是去翻/var/log/messages或者dmesg这当然没错但信息可能过于庞杂。更直接的方法是使用系统专门为记录用户登录和系统运行状态设计的工具。掌握快速、准确地定位重启事件的能力能帮你迅速判断问题是源于计划内的维护、意外的电源故障、内核崩溃Panic/Oops还是潜在的安全入侵行为。今天我们就来深入聊聊在Linux下查看重启历史记录的几种核心方法、它们的原理、使用技巧以及如何解读这些信息背后的故事。2. 核心命令深度解析与实战应用查看Linux重启记录主要依赖于几个命令last、who -b、uptime以及直接查询系统日志文件。它们各有侧重组合使用才能得到完整图景。2.1last命令重启事件的忠实记录者last命令大概是用于此目的最知名、最强大的工具。它读取的是/var/log/wtmp这个二进制日志文件该文件永久性地记录所有登录和重启事件。基本用法与输出解读直接运行last命令会输出大量的登录记录。为了专注重启事件我们使用last rebootlast reboot输出通常如下reboot system boot 5.4.0-42-generic Tue Mar 26 10:15 - 13:28 (03:13) reboot system boot 5.4.0-42-generic Mon Mar 25 02:00 - 10:15 (108:15) reboot system boot 5.4.0-40-generic Sun Mar 24 18:30 - 02:00 (07:30)第一列 (reboot): 事件类型固定为“reboot”。第二列 (system boot): 说明这是系统引导事件。第三列 (内核版本): 系统重启时所使用的内核版本这对于判断是否因内核升级而重启非常有用。第四列 (日期和时间): 系统重启发生的具体时间。第五列 (-): 分隔符。第六列 (日期和时间): 系统下一次重启或当前运行的开始时间。对于最后一次重启记录这里通常显示为“still running”或直到当前时间。第七列 (括号内时间): 系统本次连续运行的时间uptime。例如(03:13)表示运行了3小时13分钟(108:15)表示运行了1天8小时15分钟。高级技巧与参数限制输出行数last -n 5 reboot或last reboot | head -5只显示最近5次重启。指定时间范围last reboot --since 2024-03-01 --until 2024-03-26查看三月份的所有重启记录。查看特定时间点的运行状态last reboot -t YYYYMMDDHHMMSS可以查看在某个精确时间点系统是否处于“运行中”状态这对于关联故障时间点非常有用。查看wtmp文件的统计信息last -f /var/log/wtmp.1可以查看归档的旧日志文件如果存在。wtmp文件通常会由logrotate进行轮转压缩为wtmp.1.gz,wtmp.2.gz等。注意/var/log/wtmp可能不存在或被清空。一些极简的Docker容器或特定配置的系统可能不记录wtmp。此外拥有root权限的用户可以手动清空此文件 /var/log/wtmp这会抹去所有历史记录在安全调查中需要留意这一点。2.2who -b命令快速获取最后一次启动时间当你只需要知道最近一次系统是何时启动的who -b命令是最快捷的选择。who -b输出示例system boot Mar 26 10:15这条命令同样读取/var/log/utmp或/var/run/utmp当前登录信息的二进制文件但其-b选项会显示系统最后一次启动的时间。它信息简洁没有历史记录适合在脚本中快速获取启动时间戳。2.3uptime命令计算运行时长与负载uptime命令提供了一个动态的视角。它告诉你系统已经运行了多久以及系统的平均负载。uptime输出示例13:28:45 up 3:13, 1 user, load average: 0.08, 0.03, 0.01up 3:13: 这是最关键的信息表示系统自最后一次启动以来已经连续运行了3小时13分钟。由此你可以反推重启时间当前时间减去3小时13分钟。load average: 1分钟、5分钟、15分钟的系统平均负载。结合重启时间可以判断重启后系统负载的恢复情况。例如如果重启后不久负载就持续飙升可能意味着有异常进程或服务。一个实用技巧将uptime与date命令结合直接计算出重启时间点。echo 系统最后一次重启时间约为: $(date -d $(uptime -s))或者如果你的uptime输出格式支持uptime -s这会直接输出系统启动的ISO格式时间如2024-03-26 10:15:32。2.4 系统日志挖掘探寻重启的“原因”上述命令告诉你“何时”重启但“为什么”重启则需要深入系统日志。这里有几个关键日志文件/var/log/messages或/var/log/syslog(取决于发行版)这是系统级日志的汇总。搜索关键词sudo grep -i reboot\|shutdown\|systemd.*startup\|kernel.*panic /var/log/messages | tail -20你可以找到像“systemd[1]: Started User Manager for UID 0.”或“kernel: [ 0.000000] Linux version ...”这样的引导日志以及可能存在的关机记录。journalctl(Systemd系统)对于使用Systemd的现代发行版如CentOS 7/RHEL 7/Ubuntu 16.04journalctl是更强大的工具。查看本次启动的日志journalctl -b查看上一次启动的日志journalctl -b -1查看特定启动的日志journalctl --list-boots会显示一个索引列表然后使用journalctl -b NN为索引号查看。筛选重启相关journalctl --list-boots本身就能清晰列出每次启动的时间戳和启动ID。要查找关机原因可以搜索journalctl | grep -i shutdown\|halt\|poweroff\|reboot/var/log/auth.log或/var/log/secure如果重启是由用户通过sudo reboot或shutdown命令发起的这里会有对应的sudo或用户会话记录。sudo grep -i reboot\|shutdown /var/log/auth.log3. 实战场景与排查思路全解析了解了工具我们来看看如何在实际工作中运用它们。3.1 场景一诊断无故重启内核崩溃/硬件问题现象服务器监控显示服务中断但很快又恢复。登录系统后发现运行时间很短。排查步骤确认重启事实首先运行uptime确认运行时间确实很短例如up 10 minutes。查看重启时间线运行last reboot记录下最近一次或几次的重启时间。深入日志寻找“罪证”检查内核日志sudo dmesg -T | grep -E -i “panic|oops|segfault|hardware error|thermal”。-T参数显示人类可读的时间戳。关注重启时间点前后的信息。一个内核“Oops”或“Panic”信息通常是软件或驱动故障的直接证据。硬件错误如CPU、内存ECC错误也可能在这里出现。检查Systemd日志sudo journalctl --since “2024-03-26 10:00” --until “2024-03-26 10:20”将时间范围设定在重启前后。查找是否有服务崩溃、被OOM Killer终止的记录。检查硬件日志对于服务器可以查看ipmitool sel list如果支持IPMI或dmidecode命令的输出寻找硬件传感器报警如过热、电压异常。关联分析对比last reboot的时间点和在dmesg/journalctl中找到的错误信息时间点。如果错误信息紧邻着重启记录之前那么它就是导致重启的元凶。3.2 场景二安全审计与合规检查需求需要生成一份报告说明系统在过去一个月内的所有重启事件及其可能原因。操作流程收集重启时间线last reboot --since 2024-02-26 --until 2024-03-26 /tmp/reboot_history.txt为每次重启寻找原因自动化脚本思路#!/bin/bash reboot_list$(last reboot --since 2024-02-26 --until 2024-03-26 | grep ‘reboot’ | awk ‘{print $4, $5, $6, $7}’) while IFS read -r line; do reboot_time$(echo $line | awk ‘{print $1“ ”$2}’) # 简化处理实际需更精确解析 echo “ 重启事件: $line ” # 在系统日志中搜索重启时间点附近5分钟内的关键错误 sudo journalctl --since “$reboot_time - 5 min” --until “$reboot_time 1 min” | grep -E -i “error|fail|panic|shutdown|stopped” | head -5 echo done “$reboot_list“重点检查非授权重启检查/var/log/auth.log在重启时间点附近是否有非root或非授权用户的sudo记录。命令sudo grep “COMMAND.*reboot\|COMMAND.*shutdown” /var/log/auth.log可以帮助定位谁执行了重启。3.3 场景三服务重启依赖与健康检查需求在脚本中判断如果系统是近期重启的则执行一些初始化或健康检查任务。实现方法#!/bin/bash # 获取系统启动时间秒级时间戳 BOOT_TIME$(date -d “$(uptime -s)” %s) CURRENT_TIME$(date %s) UPTIME_SECONDS$((CURRENT_TIME - BOOT_TIME)) # 定义“近期”为10分钟600秒内 RECENT_THRESHOLD600 if [ $UPTIME_SECONDS -lt $RECENT_THRESHOLD ]; then echo “系统于 $(date -d $BOOT_TIME) 重启距今不到10分钟。” echo “开始执行服务健康深度检查...” # 检查关键服务状态 systemctl is-active docker.service /dev/null echo “Docker服务已运行。” || echo “Docker服务未启动” # 检查磁盘挂载 mount | grep “/data” /dev/null echo “/data 分区已挂载。” || echo “警告/data 分区未挂载” # 其他初始化逻辑... else echo “系统运行稳定已持续 $(awk -v sec$UPTIME_SECONDS ‘BEGIN {printf “%d天%02d小时%02d分钟”, sec/86400, sec%86400/3600, sec%3600/60}’)。执行常规检查...” fi4. 常见问题、进阶技巧与避坑指南4.1 为什么我的last reboot命令没有输出这是最常见的问题之一可能有以下原因/var/log/wtmp文件不存在或为空某些最小化安装的系统或容器镜像为了节省空间可能不安装utmp/wtmp相关的包如util-linux的特定模块或默认不记录。检查文件是否存在ls -lh /var/log/wtmp。文件被清空或轮转管理员可能手动清空了它 ( /var/log/wtmp)。或者logrotate将其轮转并压缩了你可以尝试last -f /var/log/wtmp.1或zcat /var/log/wtmp.1.gz | last。权限问题/var/log/wtmp通常权限是644属主为root:utmp。如果你的用户不在utmp组可能无法读取。使用sudo last reboot。系统从未重启过虽然罕见但确实有可能。用who -b和uptime交叉验证。解决方案如果确定需要记录可以手动创建并设置正确的权限但历史记录已丢失sudo touch /var/log/wtmp sudo chown root:utmp /var/log/wtmp sudo chmod 664 /var/log/wtmp更根本的方法是检查并安装必要的软件包如util-linux。4.2uptime显示的时间不准确或很奇怪时区问题uptime -s和who -b输出的系统启动时间通常是UTC时间。如果你的系统时区设置不是UTC在手动计算时需要转换。使用date -d “$(uptime -s)”可以自动按本地时区显示。系统休眠/挂起uptime计算的是内核运行时间。如果系统经历了休眠Suspend to RAM或挂起到磁盘Hibernate唤醒后uptime会继续累加而last reboot不会增加新记录。此时uptime反映的不是最后一次冷启动后的时间。要查看真正的启动时间仍需依赖last reboot或who -b。4.3 如何永久保存更长时间的重启历史默认的wtmp日志轮转策略可能只保留几周的数据。如果你有合规性要求需要长期归档修改logrotate配置编辑/etc/logrotate.conf或/etc/logrotate.d/下的相关配置如syslog或rsyslog增加wtmp的保留周期和副本数量。/var/log/wtmp { monthly # 改为每月轮转一次 create 0664 root utmp minsize 1M rotate 24 # 保留24个月2年的归档 }注意修改后需重启logrotate服务或等待其下次自动运行。使用集中式日志系统将/var/log/wtmp和系统日志通过rsyslog或syslog-ng转发到ELKElasticsearch, Logstash, Kibana、Splunk、Graylog等集中式日志管理平台。在这些平台上你可以轻松地进行跨主机、跨时间段的查询和分析。自定义脚本归档编写一个每日或每周运行的cron job使用last reboot命令将输出追加到一个自定义的归档文件中。4.4 在容器化环境中如何查看重启记录容器通常没有独立的wtmp文件也没有systemd。容器的“重启”指的是容器进程的重新创建。查看容器重启次数和最后启动时间使用docker inspect --format‘{{.Name}} {{.RestartCount}} {{.State.StartedAt}}’ container_id。查看容器内进程的运行时间进入容器后uptime命令反映的是容器内PID命名空间的运行时间即容器进程的启动时间。但容器内的/var/log/wtmp通常不存在或不可靠。最佳实践容器的生命周期管理应通过编排工具如Kubernetes的日志或事件系统来查看。例如在K8s中kubectl describe pod pod_name可以查看Events其中会记录容器的创建、重启、退出等信息。4.5 一个综合性的健康检查脚本示例将上述知识整合我们可以创建一个简单的系统健康检查脚本重启历史是其中关键一环。#!/bin/bash # 文件名system_health_check.sh echo “ 系统健康检查报告 ” echo “生成时间$(date)” echo “主机名$(hostname)” echo “” echo -e “\n1. 系统运行状态” uptime echo -e “\n2. 最近5次重启记录” last -n 5 reboot 2/dev/null || echo “警告无法读取 wtmp 日志。” echo -e “\n3. 最后一次启动详情” who -b echo -e “\n4. 关键服务状态” services(“docker” “sshd” “nginx” “mysql”) for svc in “${services[]}”; do if systemctl is-active --quiet ${svc}.service 2/dev/null; then status“运行中” else status“未运行/未安装” fi echo “ - $svc: $status” done echo -e “\n5. 重启前后关键错误日志摘要最近24小时” sudo journalctl --since “24 hours ago” | grep -E -i “(panic|oops|segfault|hardware error|fatal|failed to start)” | tail -10 echo -e “\n6. 磁盘使用率超过80%的警告” df -h | awk ‘NR1 || $50 80 {print}’ echo “” echo “检查完成。”这个脚本提供了一个快速查看系统概况的入口其中重启历史是评估系统稳定性的首要指标。掌握查看Linux重启历史的方法就像是拥有了系统运维的“时光机”。它不仅能帮你快速定位问题更是理解系统行为、进行安全审计和容量规划的基础。从简单的last reboot到复杂的日志关联分析每一步都要求你对系统有更深的理解。希望这篇详细的指南能让你下次面对“服务器为什么挂了”这个问题时能更加从容不迫直击要害。记住清晰的日志和准确的记录是稳定系统的基石。