Linux journalctl 重启后日志不见怎么办：--list-boots、持久化目录与核对方法

机器重启完，值班的同事执行 journalctl -b -1，结果完全查不到旧日志。这时候别直接断定journald丢了数据：有些主机只是没提前建好持久化存储文件夹，另一些主机其实已经留存了历史记录，只是查询范围默认停留在当前启动周期里而已。

绝大多数重启后日志消失的问题，都不是文件损坏，要么是你当前的查询范围没切到上一次启动，要么是journald默认用内存里的易失存储，没把日志持久写到磁盘上。

先用 journalctl --list-boots 判断日志是不是真的丢了

排查从启动列表开始，别上来就翻几万行日志。下面这条命令会列出journald能识别到的所有启动编号、启动ID、起止时间：

journalctl --list-boots

如果输出里同时出现 0 和 -1，说明上一次启动的记录还完整留着，接着直接运行：

journalctl -b -1 -p warning..alert --no-pager

这里的 -p warning..alert 只是先缩小返回内容的噪声范围。如果列表只有一行当前启动的记录，journalctl -b -1 查不到结果就是正常情况，下一步直接检查存储位置和配置，不用反复调整查询参数浪费时间。

为什么重启后只剩当前启动：内存日志和持久化日志的区别

systemd-journald 可以把日志放在内存里的易失目录，也可以写入磁盘上的持久化文件夹。最常见的情况就是本次运行期间 journalctl 能看到完整的所有输出，重启后旧记录直接消失；这基本说明日志还存在内存目录里，持久化文件夹没有被正确配置生效。

先查当前的磁盘占用和存储位置：

journalctl --disk-usage
sudo ls -ld /run/log/journal /var/log/journal

别看到目录存在就直接默认历史日志肯定完整。日志写入还可能受磁盘剩余空间、日志保留上限、机器异常断电和服务启动时机的影响，排障的时候要把目录状态、配置内容和实际启动列表结合起来判断。

用 Storage=persistent 把下一次重启前的线索留下来

推荐把本地自定义调整放在 /etc/systemd/journald.conf.d/，这样不会直接覆盖发行版自带的主配置文件，后续升级系统也不会把你的自定义设置冲掉：

sudo mkdir -p /var/log/journal
sudo tee /etc/systemd/journald.conf.d/20-persistent.conf >/dev/null 

Storage=persistent 的作用不是让你无限量永久保存所有日志，而是告诉 journald 优先使用持久化目录落盘。日志保留多久、最多占用多少空间，还要结合 SystemMaxUse、SystemKeepFree 等限制参数按主机的磁盘容量规划，别为了存历史日志把系统盘撑满。

改完配置之后先不用重启整台机器，先写一条你能轻易识别的测试记录：

logger -t journal-persistence-check "boot-history-check-20260724"
journalctl -t journal-persistence-check -n 5 --no-pager

重启后怎么做一次完整的复查验证

真正的有效性验证一定要跨过一次系统重启。重启前先记好当前的启动ID和你刚写的测试标记，机器启动完成之后按下面的顺序核对：

journalctl --list-boots
journalctl -b -1 -t journal-persistence-check --no-pager
journalctl -b -1 -u ssh.service -n 80 --no-pager

如果第二条命令能找到你刚才写的 boot-history-check-20260724，说明持久化日志配置已经生效，日志确实跨过重启保留下来了。第三条用来确认按服务筛选的常用查询路径也能正常工作；里面的服务名要换成你自己环境的实际单元名称，不能直接照搬 ssh.service。

要是查完还是没有历史启动记录，就按“配置是否生效 → 目录是否可写 → 服务是否正常 → 磁盘是否已满”的顺序一步步排查：

• systemd-analyze cat-config systemd/journald.conf：确认最终合并加载的配置里确实出现 Storage=persistent。
• systemctl status systemd-journald --no-pager：查看服务运行状态和启动阶段的报错信息。
• sudo find /var/log/journal -maxdepth 2 -type f -ls：确认对应的存储文件夹下有 journal 数据文件，而不是空目录。
• df -h /var：磁盘空间满了的情况下，哪怕开了持久化配置也没法新写入内容。

几个容易误判的边界场景

只创建目录但不重载服务

你手动建好目录之后，已经在运行的 journald 不一定会立刻切换到新的存储路径。用 systemctl restart systemd-journald 让配置和目录重新被服务加载，再写入测试日志验证。

把 -b -1 当成“上一条日志”

-b -1 里的 -1 指代的是上一次系统启动的完整周期，不是上一条日志，也不是上一个小时的内容。要查询单条记录或者指定时间范围应该使用 --since 和 --until。

只看服务日志，不看启动列表

服务名写错、目标单元在上一次启动里根本没运行，都可能让 -u 查询结果为空。先查完完整的 --list-boots，再按启动编号和服务状态缩小排查范围。

相关问题

journalctl -b -1 没有输出是不是日志损坏？

不一定。先看 journalctl --list-boots 的输出；如果输出里没有 -1 对应的启动记录，优先排查易失存储和持久化目录的配置问题。

/var/log/journal 一定要手动创建吗？

不同发行版和安装方式可能默认已经建好这个目录。手动创建不是唯一方案，但确认目录存在、配置正确、权限正常就能形成完整的持久化闭环。

journalctl 会无限保存日志吗？

不会。journald 的存储仍会受磁盘剩余空间、大小上限和自动清理策略影响；生产环境的主机要为 /var 预留足够存储空间，定期查看 --disk-usage 的占用情况。

小结

重启后查不到旧日志，第一步是确认启动记录列表，第二步是确认 journald 有没有正常使用 /var/log/journal，最后用自定义的测试标记跨重启做完整校验。把“命令没查到返回”和“日志真的没保存”分开验证，通常比反复扩大查询范围更快定位到根因。