2026年Ubuntu 22.04如何查看系统重启时间及原因？

大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。

html

在 Ubuntu 22.04 中，uptime 显示的是内核自上次启动以来的连续运行时长（基于 jiffies 或 CLOCK_MONOTONIC），而 last reboot 依赖 /var/log/wtmp 记录的 runlevel 切换事件。二者不一致的根本原因在于：uptime 不受系统时间跳变影响，而 wtmp 时间戳依赖当时 systemd-timedated 的本地时钟状态。若发生 NTP 调整、手动 date -s 或 RTC 漂移，last reboot 可能显示“未来时间”或明显偏移。验证方式：

timedatectl status | grep -E "(Local time|System clock|RTC time|NTP enabled)"

若 NTP enabled: no 或 System clock synchronized: no，所有时间类诊断均需先校准时间——否则后续分析全失准。

journalctl --list-boots 输出形如：

BOOT ID OFFSET START END 5a3b...c12f -0 Thu 2024-06-20 14:22:18 CST still booted 8e9d...f45a -1 Wed 2024-06-19 03:11:02 CST Thu 2024-06-20 14:22:17 CST

但该命令不提供触发原因。需结合 journalctl -o json -b -1 _TRANSPORT=kernel 过滤内核启动标记，并交叉比对 _BOOT_ID 字段。关键技巧：使用 --all --no-pager 避免截断，配合 jq 提取上下文：

journalctl -o json -b -1 | jq -r 'select(.SYSLOG_IDENTIFIER=="kernel" and (.MESSAGE | contains("Linux version") or .MESSAGE | contains("Booting")))' | head -n 3

下表归纳四类重启场景的核心日志指纹与验证路径：

重启类型典型日志线索（-b -1）辅助验证命令持久化依赖手动重启（sudo reboot） systemd[1]: Received SIGTERM from PID 1 (systemd)... + Stopped target Reboot. last -x | grep shutdown ✅ wtmp + journal persistent 内核 panic kernel: Kernel panic - not syncing: Attempted to kill init!（末尾无正常 shutdown 日志） dmesg -T -l emerg,alert,crit | tail -20 ⚠️ 仅当 Storage=persistent 且 panic 前 journald 刷盘成功电源事件（AC loss/UPS low） acpid[xxx]: received event "power/button pressed" 或 kernel: PM: suspend entry (deep) 后无 resume cat /sys/firmware/acpi/interrupts/power ✅ 需 acpid 服务启用 systemd crash（PID 1 异常终止） systemd[1]: Caught , dumped core as pid xxxxx. + 缺失 Started Update UTMP about System Runlevel Changes coredumpctl list systemd | tail -5 ✅ 需 SystemMaxUse= 足够 + Storage=auto/persistent

当 journalctl 因 panic/断电丢失数据时，必须启用多源印证：

kern.log 回溯：Ubuntu 22.04 默认启用 rsyslog 的 kernel facility 转发。检查 /var/log/kern.log* 中最近 gzip 归档文件：zgrep -h "Kernel panic|Oops|Hardware Error" /var/log/kern.log*
dmesg 持久化验证：运行 sudo dmesg -T --level=err,alert,crit,emerg —— 注意其时间基于 boot-time clock，不受 NTP 影响，但仅保留最近一次启动的 ring buffer（除非配置 kernel.dmesg_restrict=0 和 log_buf_len 参数）
硬件层证据：读取固件日志：sudo fwts --show-progress --log-level=high acpi 2>/dev/null | grep -A5 -B5 "reset|power"

为确保重启动因可追溯，须在 /etc/systemd/journald.conf 中强制以下项：

Storage=persistent Compress=yes SyncIntervalSec=5s RateLimitIntervalSec=0 SystemMaxUse=1G MaxRetentionSec=1year

并启用 systemd-journal-flush.service 确保关机前刷盘。验证配置生效：sudo systemctl restart systemd-journald && journalctl --disk-usage。同时，禁用 logrotate 对 /var/log/journal/* 的干预——journald 自身管理轮转。

以下 Bash 脚本（保存为 reboot-analyzer.sh）自动执行上述逻辑：

#!/bin/bash BOOT_ID=$(journalctl --list-boots | head -n2 | tail -n1 | awk '{print $1}') echo "== Boot ID: $BOOT_ID ==" journalctl -b -1 -o short-iso --no-pager | awk '/systemd[1]:.*Received SIGTERM/ || /Kernel panic/ || /ACPI:.*power/ || /systemd[1]:.*Caught/ {print}' | head -10 echo "--- dmesg emerg/crit ---" dmesg -T -l emerg,crit | tail -5 echo "--- kern.log panic traces (last 3 days) ---" find /var/log -name "kern.log*" -mtime -3 -exec zgrep -l "panic|Oops" {} ; 2>/dev/null | xargs -r zgrep -H "panic|Oops" | tail -3

执行前赋予执行权限：chmod +x reboot-analyzer.sh && sudo ./reboot-analyzer.sh。

graph TD A[uptime] -->|monotonic clock| B{时间是否可信？} C[last reboot] -->|wtmp timestamp| B D[journalctl --list-boots] -->|journal timestamp| B B -->|否| E[执行 timedatectl set-ntp true
timedatectl set-timezone Asia/Shanghai] B -->|是| F[交叉比对三者时间差 ≤ 5s？] F -->|否| G[检查 /etc/default/rcS 中 UTC=yes/no 与硬件时钟设置] F -->|是| H[进入重启动因深度分析]

2026年Ubuntu 22.04如何查看系统重启时间及原因？

相关推荐