journald Storage=persistent 保留重启前日志

如果服务器重启后只能看到本次启动的日志，先看日志是否只落在 /run/log/journal。这个目录通常位于运行期文件系统，重启后可能被清空。把 Storage=persistent 放进 journald 配置后，systemd-journald 会优先使用 /var/log/journal；磁盘暂时不可写时才回退到 /run/log/journal。这样既保留重启前记录，也不会把“配置已写入”误认为“日志已经成功落盘”。

官方文档：https://www.freedesktop.org/software/systemd/man/252/journald.conf.html

先分清运行期日志和持久日志

我排查这类问题时先不急着重启服务，而是观察两个目录：/run/log/journal 适合早期启动或持久目录不可写时临时接收日志，/var/log/journal 才是跨重启保存的目标位置。默认 Storage=auto 会根据 /var/log/journal 是否存在来选择模式，因此有些机器“看起来没配置”也能持久化，有些精简系统却只保留当前启动。

用 drop-in 文件启用 Storage=persistent

把设置写成独立片段，后续升级或排查时更容易定位：

# 创建 journald 的本地配置目录，避免覆盖发行版主文件
sudo install -d -m 0755 /etc/systemd/journald.conf.d

# 写入持久化策略；配置键必须放在 [Journal] 段
sudo tee /etc/systemd/journald.conf.d/10-persistent.conf 

这里的关键不是单独重启 systemd-journald，而是确保目标目录存在且可写。官方说明里，persistent 会优先使用 /var/log/journal，早期启动阶段可能先写入运行期目录，再由 flush 过程迁移。

目录权限和空间上限决定最终结果

在最小化系统或只读根文件系统上，配置正确仍可能无法持久化。先确认目录、挂载点和写权限：

# 查看持久日志目录及所在文件系统；失败时重点检查挂载和权限
sudo install -d -m 2755 -o root -g systemd-journal /var/log/journal
findmnt /var/log/journal
sudo journalctl --disk-usage

# 只在确实需要时设置上限，避免日志挤占业务磁盘
sudo tee /etc/systemd/journald.conf.d/20-retention.conf 

SystemMaxUse 控制持久日志占用，RuntimeMaxUse 控制运行期日志占用。它们是边界，不是保证一定保留多久；高频服务仍可能较快轮转旧文件。

用三个检查确认重启前日志可读

检查时不要只看一行最新日志，至少组合下面三项：

# 查看可用的启动批次；出现 -1 才说明上一轮启动有可读记录
journalctl --list-boots

# 读取上一轮启动的最后 50 行，验证跨重启查询路径
journalctl -b -1 -n 50 --no-pager

# 查看 journald 当前实际使用的存储信息和最近错误
journalctl -u systemd-journald -b --no-pager
sudo journalctl --disk-usage

如果没有 -1 启动批次，优先检查 /var/log/journal 是否可写、配置片段是否位于正确目录，以及是否在首次重启前执行了 journalctl --flush。若磁盘在启动阶段不可写，日志暂存到 /run/log/journal 是设计中的回退行为，修复挂载后再刷新即可。

常见问题

只设置 Storage=persistent，需要手动创建 /var/log/journal 吗？

不一定，journald 会在需要时创建目录；但在严格权限、只读根目录或自定义挂载环境中，提前创建并确认属主组更稳妥。

把 Storage 改成 persistent 会自动恢复已经丢失的日志吗？

不会。它只能保存配置生效之后仍在内存或运行期目录中的可迁移记录，已经因重启清空的日志无法恢复。

为什么配置正确却仍然写进 /run/log/journal？

通常是持久目录不存在、挂载尚未就绪、文件系统只读或空间不足。先看 findmnt、权限和 journalctl --disk-usage，再看 journald 服务日志。

持久化的价值是给故障定位留下跨重启上下文，但它仍受磁盘、权限和保留策略约束。把配置片段、目录检查和启动批次查询放进上线清单，通常比只改一个参数更可靠。