登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  linux

journalctl 重启后查不到旧日志:启动编号与持久化存储怎么一起核对

来源:17golang原创

时间:2026-09-04 01:35:35 440浏览 收藏

机器刚重启完,值班记录里最需要的往往不是当前几分钟的日志,而是上一轮启动为什么结束。此时直接执行 journalctl -b -1 却没有输出,通常不能马上归因于日志丢失:可能根本没有可见的上一轮启动,也可能 journalctl 读的目录和 journald 实际写入的目录不是同一个。

要点速览
  • journalctl --list-boots 先证明历史启动编号是否存在,再解释 -b -1
  • --directory 要和 --list-boots-b -1 一起使用,才能排除读错目录。
  • Storage=auto 是否落盘,关键看 /var/log/journal 的存在和可写状态。

先用 journalctl --list-boots 证明旧启动是否存在

先不要改配置,执行:

journalctl --list-boots
journalctl -b -1 -n 50 --no-pager

--list-boots 会列出相对启动编号、启动 ID 和时间范围。当前启动通常是 0,上一轮是 -1;如果列表只有当前启动,-b -1 没有结果就是符合现状的,并不能说明查询参数写错。列表中有 -1,但第二条仍为空,才进入目录核对。

这里的检查点很具体:负数启动编号要和你要调查的重启时间相符,末尾时间不能早到另一台机器或另一套根文件系统。先把“没有上一轮记录”和“有记录但读不到”分开,后面的判断才不会跑偏。

再用 journalctl -D 锁定实际读取的日志目录

journalctl 的默认搜索范围可能同时涉及运行时和系统 journal。把目录写在命令里,能避免当前 shell 的环境、容器根目录或挂载状态造成误判。先列出目录,再按同一目录筛选:

sudo find /var/log/journal /run/log/journal -maxdepth 2 -type f -name '*.journal*' -print
sudo journalctl --directory=/var/log/journal --list-boots
sudo journalctl --directory=/var/log/journal -b -1 -n 50 --no-pager

这里要同时看六个实体:journalctl --list-boots 负责给出 启动编号journalctl -b -1 负责按上一轮筛选,journalctl --directory 把查询绑定到 /var/log/journal/run/log/journal。如果显式指定 /var/log/journal 后能看到 -1,默认命令看不到,问题就是读取范围不一致。

journalctl 启动编号与 journalctl --directory 读取目录的 Linux 日志边界框图
图1:查看查询边界与目录边界中的启动编号和 journal 路径,判断 -b -1 是无历史记录还是读错位置。

最后核对 Storage=auto 与 /var/log/journal 是否真的持久化

目录存在不等于正在使用,配置也不等于已经成功写盘。先找出实际生效的 Storage 配置,并检查两个目录:

sudo grep -RnsE '^[[:space:]]*Storage[[:space:]]*=' \
  /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
sudo ls -ld /var/log/journal /run/log/journal 2>/dev/null

Storage=auto/var/log/journal 存在时倾向持久化,否则会使用 /run/log/journal 这类易失性位置;Storage=persistent 优先选择磁盘目录,但磁盘不可写时仍可能回退到运行时目录。启动阶段的 systemd-journal-flush.service 会处理易失性日志向持久化位置的切换,不能只看配置文件就下结论。

观察到的组合更可能的结论下一项核对
只有 -1,默认查询有结果历史记录正常记录启动 ID 与时间范围
显式 --directory 才有 -1默认读取范围不对确认挂载、容器根目录和目录参数
只有 /run/log/journal,重启后编号消失日志主要是易失性的检查 Storage 与 /var/log/journal 可写性
Storage=auto、Storage=persistent 与 systemd journal 持久化目录关系框图
图2:对照配置语义、两个 journal 目录和 flush 服务,判断重启后历史日志是否具备落盘条件。

把修复动作限定在持久化目录与重启后的反向验证

如果确认缺少持久化目录,可以先按发行版权限策略补齐目录,再让 systemd 重新识别:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo journalctl --flush
sudo journalctl --list-boots

这组动作的目的不是清理日志,而是把保存位置和切换动作固定下来。若配置文件显式写了 Storage=volatile,先改成符合维护策略的值并重载相关服务;生产机器还要确认磁盘可写、目录属主和容量上限。修复后的立即检查只能证明当前日志已可见,最终验证要放到下一次重启之后:

journalctl --list-boots
journalctl -b -1 -n 100 --no-pager

下一次启动后仍出现上一轮的负数启动编号,并能按目标时间读到记录,才算完成闭环。

常见问题

为什么 --list-boots 只有 0,没有 -1?

当前可见的 journal 里没有上一轮启动记录,常见原因是刚安装、日志使用易失性目录,或旧日志已经被清理。先确认目录和 Storage,再决定是否需要等待下一次重启验证。

Storage=auto 一定会把日志写进磁盘吗?

不一定。它会根据 /var/log/journal 是否存在选择持久化倾向;磁盘目录不可写、尚未创建或被覆盖配置改变时,仍可能落到 /run/log/journal

为什么指定 /var/log/journal 后反而查不到?

这通常说明该目录为空、权限不可读,或历史日志实际仍在另一个 journal 目录。把两个目录的文件列表、目录参数和 --list-boots 输出放在一起比较,不要只重复 -b -1

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>