journalctl 为什么报错？systemd init 系统是前提

1. 为什么你看到的 journalctl 报错信息总像在说“外语”——从 init 系统本质讲起

journalctl 这个命令，表面上只是查日志的工具，但它的行为逻辑、报错方式、甚至能否运行，全都牢牢绑定在 systemd 是否真正作为 PID 1 的 init 系统启动 这一底层事实上。这不是一个可选配置，而是整个 Linux 启动链路的基石。我第一次在一台用 sysvinit 启动的 Debian 旧服务器上敲下 journalctl -u nginx ，得到的却是那句经典报错：

Failed to connect to bus: No such file or directory

后来换成更直白的提示：

System has not been booted with systemd as init system (PID 1). Can't operate.

当时以为是服务没装好，反复重装 systemd-journald ，甚至怀疑是权限问题。折腾两小时后才意识到：这台机器压根就没用 systemd 启动——它的 /sbin/init 指向的是 /lib/sysvinit/init ，不是 /lib/systemd/systemd 。 journalctl 不是“查日志的通用命令”，它是 systemd 的专属控制台接口 ，就像 MySQL 客户端只能连 MySQL 服务，不能连 PostgreSQL 一样。

这个认知偏差，是绝大多数人卡在 journalctl 入门第一关的根本原因。它不提供“兼容模式”，也不做优雅降级。当系统没有以 systemd 为 init 启动时， journalctl 就会直接拒绝工作，而不是尝试读取 /var/log/messages 或其他传统日志路径。这种设计哲学很“systemd”：明确边界、拒绝模糊、强调一致性。所以，所有关于 journalctl 的实操，必须前置一个确定性判断：你的系统是否真的运行在 systemd 之下？

验证方法极其简单，且必须在任何操作前执行：

# 查看 PID 1 进程名（最权威）
ps -p 1 -o comm=

# 查看 /proc/1/cmdline（原始启动参数）
cat /proc/1/cmdline | tr '\0' '\n' | head -n1

# 检查 systemd 是否在运行（辅助验证）
systemctl list-units --type=service --state=running | grep journald

提示： ps -p 1 -o comm= 是黄金标准。如果输出是 systemd ，一切 OK；如果是 init 、 runit 、 openrc 或其他，那么 journalctl 就注定无法工作——这不是 bug，是设计使然。强行安装 systemd-journald 并不会让 journalctl 活过来，因为它的通信总线（D-Bus）和核心守护进程（ systemd-journald.service ）根本不会被启动。

很多教程跳过这一步，直接教 journalctl -f 或 -u sshd ，结果新手在非 systemd 环境下照着敲，第一行就报错，信心瞬间崩塌。而真正的从业者，会在打开终端后的前三秒内先跑一遍 ps -p 1 -o comm= 。这不是多此一举，是建立操作信任的基础。就像医生开药前必问过敏史，程序员查日志前必验 init 系统。

这也解释了为什么网络热搜里，“system has not been booted with systemd as init system” 长期高居榜首——它不是一个技术故障，而是一个身份认证失败。 journalctl 在说：“我不认识你，你不是我的主人。” 解决方案从来不是修 journalctl ，而是确认你的系统是否本该用它。如果你的 VPS 提供商默认使用 OpenRC，或者你手动编译内核时禁用了 CONFIG_SYSTEMD ，那 journalctl 就永远是个摆设。接受这个事实，比试图绕过它要高效得多。

2. journalctl 的三大核心能力：不只是“翻页查日志”，而是日志的全生命周期管理

很多人把 journalctl 当成 tail -f /var/log/syslog 的替代品，这是对它能力的巨大低估。 journalctl 的本质，是 systemd 日志子系统的用户态前端 ，它管理的不是静态文件，而是一个结构化的、带元数据的、可索引的日志流。它的能力可以清晰划分为三个不可替代的维度： 检索（Query）、过滤（Filter）、归档（Archive） 。理解这三者，才能跳出“查错”的单一视角，进入“日志治理”的专业层面。

2.1 检索：用结构化元数据精准定位，而非全文扫描

传统日志如 /var/log/messages 是纯文本，搜索靠 grep ，效率低、精度差。 journalctl 的日志条目是二进制结构体，每个条目都附带数十个字段，例如：

• _PID : 产生日志的进程 PID
• _UID : 进程所属用户 UID
• _GID : 进程所属组 GID
• _COMM : 进程命令名（如 sshd , nginx ）
• _EXE : 进程可执行文件绝对路径
• _SYSTEMD_UNIT : 所属 systemd 单元名（如 nginx.service ）
• _HOSTNAME : 日志来源主机名
• _TRANSPORT : 日志传输方式（ stdout , journal , kernel ）

这意味着你可以用 journalctl _COMM=sshd 直接筛选出所有 sshd 进程产生的日志，无需担心 grep sshd 误匹配到包含 “sshd” 字符串的其他日志行（比如某条错误信息里提到 “failed to start sshd”）。更进一步， journalctl _SYSTEMD_UNIT=nginx.service _PID=1234 能精确锁定某个 nginx worker 进程在特定时间点的行为，这是 grep 永远做不到的。

我在线上排查一个间歇性 502 错误时，Nginx 日志只显示 upstream prematurely closed connection ，但不知道是哪个 upstream server。用 journalctl -u nginx --since "2024-05-20 14:00:00" --until "2024-05-20 14:05:00" 拉出五分钟日志后，再结合 --output=json-pretty 导出为 JSON，发现每条日志都带有 _CMDLINE 字段，里面完整记录了 Nginx worker 启动时的 -c 配置文件路径和 -p 前缀路径。这让我立刻定位到是某台 upstream 的证书路径配置错误，而非 Nginx 本身的问题。这种基于元数据的穿透式分析，是 journalctl 最核心的价值。

2.2 过滤：时间、服务、优先级的三维坐标系

journalctl 的过滤不是简单的“包含关键词”，而是构建一个三维坐标系： 时间轴（When）、实体轴（What）、严重性轴（How Critical） 。

• 时间轴 ： --since 和 --until 支持极其灵活的语法。 --since "2 hours ago" 、 --since "yesterday" 、 --since "2024-05-20" 、 --since "2024-05-20 14:30:00" 全部有效。更重要的是， --since 默认是相对当前时间，而 --until 可以是绝对时间，这让你能轻松划定任意时间窗口。我习惯用 journalctl --since "10 minutes ago" --no-pager 快速查看最近异常，比 tail -n 100 /var/log/syslog | grep error 准确十倍。

• 实体轴 ： -u （unit）、 -p （priority）、 -o （output）、 -n （lines）等选项构成实体选择器。 -u nginx.service 只看 nginx 服务； -u nginx.service --all 还包括其依赖的 socket、timer 单元； -p err 只看错误级别； -p 3 （数值对应 err ）则更精确。 -o json-pretty 输出结构化 JSON，方便用 jq 做二次处理，这是运维自动化的关键一环。

• 严重性轴 ： -p 参数支持 emerg （0）、 alert （1）、 crit （2）、 err （3）、 warning （4）、 notice （5）、 info （6）、 debug （7）八个级别。 journalctl -p 3 等价于 journalctl -p err ，但数值形式在脚本中更稳定。注意： -p 0..2 是系统级致命错误，通常意味着内核崩溃或硬件故障，普通服务日志极少达到这个级别。

这三个轴可以任意组合。例如， journalctl -u docker.service -p err --since "1 hour ago" 是线上故障响应的标准命令，它能在 1 秒内给出 Docker 服务在过去一小时内所有错误日志，没有任何噪音。这种组合能力，是 journalctl 区别于所有传统日志工具的分水岭。

2.3 归档：日志的持久化、轮转与空间治理

journalctl 管理的日志默认存储在 /run/log/journal/ （易失性内存）和 /var/log/journal/ （持久化磁盘）两个位置。 /run 下的日志在重启后丢失， /var/log/journal/ 下的则永久保留——但这需要手动启用。很多发行版（如 Ubuntu）默认不创建 /var/log/journal/ ，导致 journalctl 只能查到本次启动以来的日志。

启用持久化只需两步：

# 创建目录（systemd-journald 会自动识别）
sudo mkdir -p /var/log/journal

# 重启 journald 服务（立即生效）
sudo systemctl kill --kill-who=main --signal=SIGUSR1 systemd-journald

注意：不要用 systemctl restart systemd-journald ，这会导致日志采集短暂中断。 SIGUSR1 是 systemd-journald 的“重新加载配置并切换日志文件”信号，零中断。

启用后，日志会按月分目录存储，如 /var/log/journal/0123456789abcdef0123456789abcdef/ 。 journalctl 会自动合并读取所有可用日志源。但随之而来的是磁盘空间问题。 journalctl --disk-usage 显示当前占用， journalctl --vacuum-size=500M 则将日志压缩至 500MB 以内，自动删除最老的条目。 --vacuum-time=2weeks 删除两周前的所有日志。这些命令不是“清空”，而是智能轮转，确保日志有历史纵深，又不撑爆磁盘。

我管理的 20 台生产服务器，全部配置了 SystemMaxUse=500M 和 MaxRetentionSec=4week 在 /etc/systemd/journald.conf 中，并通过 Ansible 统一推送。这样既保证了故障回溯能力，又避免了因日志无节制增长导致的磁盘告警。 journalctl 的归档能力，让它从一个临时调试工具，升级为一个可管理、可预测、可审计的日志基础设施组件。

3. 从 “journalctl -f” 到 “journalctl --no-pager --output=short-iso”：那些没人告诉你的终端适配技巧

journalctl -f （follow 模式）几乎是所有人学会的第一个 journalctl 命令，但它只是冰山一角。真正决定你日常使用体验的，是那些影响终端显示、交互效率和信息密度的“小参数”。它们不改变日志内容，却极大改变你读取日志的效率和准确性。这些技巧，往往只在资深运维的 .bashrc 里流传，很少出现在官方文档的显眼位置。

3.1 终端分屏下的“滚动地狱”：为什么 less 分页器是最大敌人

journalctl 默认使用 less 作为分页器。在单终端窗口下，这很合理；但在 tmux 或 screen 的分屏环境中， less 会接管整个 pane，导致你无法用鼠标滚轮查看历史，也无法用 Ctrl+Shift+Up 快速翻页。更糟的是， less 的搜索（ / ）和 journalctl 的原生搜索（ --grep ）是两套体系，容易混淆。

解决方案是彻底禁用分页器：

# 临时禁用
journalctl --no-pager -u nginx.service

# 永久禁用（写入 shell 配置）
echo 'export SYSTEMD_PAGER="cat"' >> ~/.bashrc
source ~/.bashrc

SYSTEMD_PAGER="cat" 让 journalctl 直接输出到 stdout，不经过任何分页器。配合 | head -n 50 或 | tail -n 100 ，你可以完全掌控输出长度。在自动化脚本中， --no-pager 是强制要求，否则脚本会卡在 less 等待用户输入。

提示： SYSTEMD_PAGER 环境变量优先级高于 PAGER ，所以即使你设置了 export PAGER=less ， journalctl 仍会尊重 SYSTEMD_PAGER 。这是 systemd 的设计，确保日志输出行为可预测。

3.2 时间戳格式：ISO 8601 是唯一值得信赖的标准

journalctl 默认的时间戳是 May 20 14:30:22 这种本地化格式，它有两个致命缺陷： 无法排序、无法跨时区比较 。 May 20 排在 Jan 01 前面， 14:30 在 09:15 后面，但字符串排序时 Jan < May ， 09 < 14 ，导致 sort 命令失效。更麻烦的是，当你的服务器分布在东京、法兰克福、旧金山时，“14:30” 指代的时间完全不同。

正确做法是强制使用 ISO 8601 格式：

# 短格式（推荐日常使用）
journalctl --output=short-iso -u nginx.service

# 长格式（含微秒，适合精确排障）
journalctl --output=short-iso-precise -u nginx.service

# 完整 ISO（含时区，适合审计）
journalctl --output=full-iso -u nginx.service

short-iso 输出 2024-05-20T14:30:22.123456+0800 ，这是一个可被任何编程语言解析、可被 sort 正确排序、可被 awk 精确切分的标准化时间戳。我在写日志分析脚本时，第一行永远是 journalctl --since "$START_TIME" --until "$END_TIME" --output=short-iso --no-pager | sort ，确保时间线绝对准确。 short-iso-precise 还包含微秒，对于排查毫秒级延迟问题（如数据库连接池耗尽）至关重要。

3.3 输出格式：JSON 是自动化时代的唯一通行证

journalctl 的默认文本输出（ short ）对人友好，但对机器极不友好。字段之间用空格分隔，但日志消息本身可能包含空格，导致 awk '{print $5}' 这样的提取完全不可靠。 --output=json 或 --output=json-pretty 则输出标准 JSON，每个字段都是明确的键值对。

# 获取最近 10 条 nginx 错误的 JSON
journalctl -u nginx.service -p err -n 10 --output=json --no-pager | jq '. | {time: .__REALTIME_TIMESTAMP, unit: ._SYSTEMD_UNIT, message: .MESSAGE}'

# 输出示例：
# {
#   "time": "1716212422123456",
#   "unit": "nginx.service",
#   "message": "connect() failed (111: Connection refused) while connecting to upstream"
# }

jq 是处理 JSON 日志的瑞士军刀。上面的命令用 jq 提取了时间戳（微秒级）、单元名和消息体，干净利落。 __REALTIME_TIMESTAMP 是 systemd 内部的微秒时间戳，比 _TIMESTAMP 更精确，是做性能分析的黄金字段。 journalctl 的 JSON 输出，是打通日志、监控、告警三大系统的桥梁。没有它，你的 ELK 或 Loki 集成就是空中楼阁。

3.4 实战技巧：一个命令解决 80% 的日常查询

综合以上所有技巧，我日常使用的 journalctl 命令模板是：

alias jctl='journalctl --no-pager --output=short-iso --since "10 minutes ago"'

然后，针对不同场景：

• 查看某服务最新日志： jctl -u nginx.service
• 查看某服务错误： jctl -u nginx.service -p err
• 查看内核日志： jctl -k
• 查看本次启动日志： jctl -b
• 查看上次启动日志： jctl -b -1

这个 jctl 别名，是我每天敲上百次的命令。它消除了分页器干扰、统一了时间格式、限定了时间范围，让每一次日志查询都变成一次确定性的、可预期的操作。这才是 journalctl 应该有的样子：不是一堆需要记忆的参数，而是一个融入肌肉记忆的工作流。

4. systemd-journald 的隐藏配置：从 /etc/systemd/journald.conf 到 /run/log/journal 的权限迷宫

journalctl 是前台， systemd-journald 是后台守护进程，而 /etc/systemd/journald.conf 就是它的“宪法”。绝大多数人只用 journalctl ，却从不碰 journald.conf ，这就像只开车不保养发动机。这份配置文件决定了日志的存储位置、大小限制、保留策略、甚至安全级别。理解它，是掌握 journalctl 长期稳定运行的关键。

4.1 配置文件结构：全局设置与单元覆盖的双层模型

/etc/systemd/journald.conf 是一个典型的 INI 风格文件，分为 [Journal] 主节和可选的 [Journal Remote] 、 [Journal Upload] 等节。 [Journal] 节下的参数，是全局默认值。但 systemd 的精妙之处在于，它允许为 单个服务单元 覆盖这些全局设置。例如，在 /etc/systemd/system/nginx.service.d/override.conf 中添加：

[Service]
# 让 nginx 日志单独存到 /var/log/journal/nginx/
LogsDirectory=nginx
# 为 nginx 日志启用额外的字段收集
LogExtraFields=NGINX_VERSION=1.24.0

这样， nginx.service 的日志就会被标记上 NGINX_VERSION 字段，并可能被路由到独立的存储路径。这种“全局默认 + 单元覆盖”的双层模型，提供了极大的灵活性。 journald.conf 的核心参数，我按重要性排序如下：

注意：修改 journald.conf 后， 不需要重启 systemd-journald 。只需发送 SIGUSR1 信号： sudo systemctl kill --signal=SIGUSR1 --kill-who=main systemd-journald 。这是 systemd 的热重载机制，零停机。

4.2 权限迷宫：为什么 journalctl 有时提示 “Permission denied”

journalctl 的权限模型是 systemd 安全架构的核心部分。它不是简单的文件读取，而是通过 D-Bus 总线与 systemd-journald 守护进程通信。 journald 默认只允许 root 和 systemd-journal 用户组成员访问全部日志。普通用户执行 journalctl ，只能看到自己的用户会话日志（ --user ），看不到系统日志。

解决方法有两种：

• 方案一（推荐）：将用户加入 systemd-journal 组

  sudo usermod -aG systemd-journal $USER
  # 重新登录或 newgrp systemd-journal 生效
  

• 方案二：配置 journald.conf 的 ReadKMsg=yes

  [Journal]
  ReadKMsg=yes
  

  这会让 journald 读取 /dev/kmsg （内核日志），并允许非特权用户通过 journalctl -k 查看内核日志。但这不解决系统服务日志的访问问题。

权限问题常出现在容器环境或最小化安装的系统中。例如，Alpine Linux 默认不创建 systemd-journal 组， journalctl 对非 root 用户完全不可用。此时， usermod 方案是唯一正解。 journalctl 的权限设计，体现了 systemd 的理念：日志是敏感信息，访问必须受控。这不是 bug，是 feature。

4.3 存储路径详解： /run vs /var/log 的生存周期哲学

systemd-journald 默认使用两个路径：

• /run/log/journal/ ：基于 tmpfs 的内存文件系统，速度快，但 重启即失 。路径下有一个以机器 ID 命名的子目录，如 /run/log/journal/0123456789abcdef0123456789abcdef/ 。
• /var/log/journal/ ：基于磁盘的持久化存储， 重启不丢 。同样有机器 ID 子目录。

journald 的行为逻辑是： 优先写入 /run/log/journal/ ，当它存在且有空间时；当 /var/log/journal/ 被创建并启用后，它会同时写入两者，并在 /run 空间不足时，自动将 /run 中的老日志迁移到 /var/log 中 。这是一种智能的“热-冷”分层存储。

验证当前日志源：

# 查看 journald 正在使用的日志目录
sudo systemd-journalctl --disk-usage

# 查看当前活跃的日志文件（会显示 /run 和 /var/log 两条路径）
ls -l /run/log/journal/*/system.journal
ls -l /var/log/journal/*/system.journal

/run/log/journal/ 的目录权限是 drwxr-sr-x ， systemd-journal 组有写权限； /var/log/journal/ 的权限是 drwxr-sr-x ，同样由 systemd-journal 组管理。这就是为什么将用户加入该组是解决权限问题的根本之道——你获得了对这两个路径的读取权。

我管理的生产环境，全部启用 /var/log/journal/ ，并设置 SystemMaxUse=500M 和 MaxRetentionSec=4week 。这样，即使服务器连续运行一年，日志也不会超过 500MB，且永远有最近四周的完整历史。 journald.conf 的配置，不是一次性的设置，而是日志治理的长期契约。

5. 故障排查实战：从 “No such file or directory” 到 “Cannot assign requested address” 的完整诊断链

journalctl 本身也会出错，而这些错误信息，恰恰是诊断 systemd 系统健康状况的“心电图”。网络热搜里那些高频报错，如 No such file or directory 、 Cannot assign requested address 、 Failed to get D-Bus connection ，都不是 journalctl 的 bug，而是它在向你报告更底层的系统问题。掌握这些报错的诊断链，是进阶运维的必修课。

5.1 报错链一： Failed to connect to bus: No such file or directory

这是 journalctl 最常见的报错，表面看是 D-Bus 连接失败，但根源有三层：

• Layer 1：D-Bus 服务未运行
  systemd 启动时，会自动拉起 dbus-broker 或 dbus-daemon 。如果 dbus 进程不存在， journalctl 就无法通信。检查：

  systemctl status dbus-broker  # modern systems
  systemctl status dbus         # legacy systems
  

• Layer 2：D-Bus socket 文件缺失
  D-Bus 通过 Unix socket 通信，默认路径是 /run/dbus/system_bus_socket 。如果这个文件不存在， journalctl 就会报错。检查：

  ls -l /run/dbus/system_bus_socket
  # 如果不存在，重启 dbus 服务
  sudo systemctl restart dbus-broker
  

• Layer 3： systemd-journald 守护进程崩溃
  journalctl 的后端是 systemd-journald 。如果它挂了，D-Bus 连接自然失败。检查：

  systemctl status systemd-journald
  # 如果状态是 `inactive (dead)`，重启它
  sudo systemctl restart systemd-journald
  

诊断顺序必须是：先 systemctl status systemd-journald ，再 systemctl status dbus-broker ，最后 ls /run/dbus/ 。因为 journald 是源头， dbus 是管道，socket 是接口。修复顺序也应如此：先复活 journald ，再确保 dbus 运行，最后验证 socket 存在。

5.2 报错链二： Cannot assign requested address

这个报错通常出现在 journalctl --flush 或 journalctl --rotate 时，意思是 journald 尝试绑定一个网络地址失败。这指向一个更隐蔽的问题： journald 的远程日志功能（ ForwardToSyslog=yes 或 ForwardToKMsg=yes ）被错误配置，导致它试图监听一个已被占用的端口 。

检查 /etc/systemd/journald.conf ：

[Journal]
# ForwardToSyslog=yes   # 注释掉这一行！
# ForwardToKMsg=yes     # 注释掉这一行！

ForwardToSyslog 会让 journald 将日志转发给 rsyslogd 或 syslog-ng ，这需要 journald 启动一个 UDP/TCP listener。如果 rsyslogd 已经占用了 514 端口， journald 就会报 Cannot assign requested address 。解决方案是： 除非你明确需要日志转发，否则关闭所有 ForwardTo* 选项 。 journald 的原生日志能力已足够强大，无需额外转发。

5.3 报错链三： Failed to get D-Bus connection: Operation not permitted

这个报错常见于容器环境（Docker/Podman）。容器默认以 CAP_SYS_ADMIN 能力运行，但 journalctl 需要 CAP_DAC_OVERRIDE 和 CAP_SYS_PTRACE 等更多能力才能访问宿主机的 D-Bus。在容器内执行 journalctl ，几乎必然失败。

解决方案只有两个：

• 方案一（推荐）：在宿主机上查，不在容器里查
  容器是隔离的，它的 journalctl 只能看到自己内部的日志（如果有）。系统级日志必须在宿主机查。

• 方案二：给容器加特权（仅限开发测试）

  docker run --cap-add=SYS_ADMIN --cap-add=SYS_PTRACE -it ubuntu:22.04
  

注意： --privileged 是万能钥匙，但极度危险，生产环境严禁使用。 --cap-add 是最小权限原则的体现。

5.4 终极诊断法：用 strace 追踪 journalctl 的每一步系统调用

当所有常规方法都失效时， strace 是终极武器。它能显示 journalctl 在内核层面到底做了什么：

# 追踪 journalctl 的系统调用
sudo strace -e trace=openat,connect,sendto,recvfrom journalctl -n 1 2>&1 | grep -E "(openat|connect|sendto|recvfrom)"

# 输出示例：
# openat(AT_FDCWD, "/run/dbus/system_bus_socket", O_RDWR|O_CLOEXEC) = 3
# connect(3, {sa_family=AF_UNIX, sun_path="/run/dbus/system_bus_socket"}, 110) = 0
# sendto(3, "\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 32, MSG_NOSIGNAL, NULL, 0) = 32
# recvfrom(3, "\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 2048, 0, NULL, NULL) = 32

如果 openat 失败，说明 socket 文件不存在；如果 connect 失败，说明 D-Bus 服务没起来；如果 sendto 失败，说明 journald 守护进程崩溃。 strace 的输出，就是 journalctl 的“手术记录”，它不会撒谎。

我曾遇到一个案例： journalctl 报 No such file or directory ，但 systemctl status systemd-journald 显示 active。用 strace 发现， openat 尝试打开 /run/systemd/journal/socket （一个旧路径），而不是 /run/dbus/system_bus_socket 。最终定位到是 /etc/systemd/journald.conf 中错误配置了 SystemMaxFiles=1 ，导致 journald 自行创建了一个错误的 socket 路径。 strace 是打破“黑盒”的唯一工具。

6. systemd 中的 reboot 命令：它和 journalctl 的隐秘关联

systemd 的 reboot 命令，表面看只是一个关机指令，但它与 journalctl 有着深刻的、常被忽视的关联。 reboot 不是直接调用内核的 reboot() 系统调用，而是通过 systemd-logind 服务，向 systemd 的 manager 发送一个 Reboot D-Bus 方法调用。而这个调用的全过程，会被 systemd-journald 完整记录下来，并打上特殊的 _SYSTEMD_UNIT=systemd-logind.service 和 _TRANSPORT=journal 标签。

这意味着， 每一次 reboot 、 shutdown 、 halt 命令的执行，都会在 journal 日志中留下一条不可篡改的、带时间戳和调用者信息的审计记录 。这是 journalctl 作为审计工具的核心价值。

6.1 查看重启历史： journalctl --list-boots 是真相之眼

journalctl --list-boots 命令会列出系统每次启动的 ID、时间范围和内核命令行：

$ journalctl --list-boots
-1 0123456789abcdef0123456789abcdef Mon 2024-05-20 14:30:22 CST—Mon 2024-05-20 15:45:11 CST
 0 0123456789abcdef0123456789abcdef Mon 2024-05-20 15:45:11 CST—Mon 2024-05-20 16:22:33 CST

这里的 -1 表示上一次启动， 0 表示本次启动。你可以用 journalctl -b -1 查看上一次启动的全部日志， journalctl -b 0 查看本次启动日志。 -b （boot）参数是 journalctl 最强大的时间锚点，它比 --since "1 hour ago" 更精确，因为它基于内核启动时间戳，不受系统时间漂移影响。

6.2 重启原因溯源：从 journalctl -b -1 到 systemd-analyze blame

当你发现系统莫名重启，第一步永远是：

# 查看上一次启动的最后 100 行日志
journalctl -b -1 -n 100 --no-pager --output=short-iso

# 查看上一次启动的详细时间线
systemd-analyze --boot=-1 time
systemd-analyze --boot=-1 blame | head -n 20

`systemd-an