系统服务 journal 日志放内存还是磁盘：用 Storage 和目录状态固定持久化结果

服务器重启后，journalctl -b -1 突然查不到上一轮启动记录，先别急着把问题归到日志轮转。systemd-journald 是否把日志写到磁盘，首先取决于 Storage= 的有效值，以及 /var/log/journal 这个目录是否存在；/run/log/journal 属于运行时存储，通常会随着重启清空。

Storage=auto 到底依据哪个目录决定模式

在默认 journal 命名空间中，官方手册把 Storage=auto 定义为：/var/log/journal 存在时按持久化模式工作，不存在时按易失性模式工作。对应关系很直白：persistent 优先使用磁盘上的 /var/log/journal，volatile 只使用内存文件系统下的 /run/log/journal。

这里的“内存”容易造成误解。/run 通常是 tmpfs，但判断依据不是某个进程的 RAM 用量，而是 journal 文件所在的文件系统。可以先看有效配置和目录状态：

grep -R --line-number -E '^\s*Storage=' /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
test -d /var/log/journal && echo persistent-directory-present || echo runtime-only-directory
test -d /run/log/journal && echo runtime-directory-present || echo runtime-directory-missing

如果配置文件里写了多个值，还要留意 journald.conf.d 的 drop-in。后加载的同名配置可能覆盖主文件。显式写成 Storage=volatile 时，即便手工创建了 /var/log/journal，也不能据此认为日志会跨重启保留。

journalctl --disk-usage 如何确认当前日志位置

目录存在只能说明“具备持久化条件”，不能证明当前已经完成切换。先用以下命令查看 journal 看到的总占用，再把两个目录分别列出来：

journalctl --disk-usage
findmnt -T /run/log/journal
findmnt -T /var/log/journal
find /run/log/journal /var/log/journal -type f \( -name '*.journal' -o -name '*.journal~' \) -print 2>/dev/null

journalctl --disk-usage 是总体证据，目录文件和 findmnt 是位置证据。若 /var/log/journal 不存在，而 /run/log/journal 有正在增长的 .journal 文件，通常说明当前仍是易失性存储。若两边都存在，不能简单把它们相加当成两套永久日志：启动早期可能先写运行时目录，持久化启用后再由 flush 处理。

若只改了配置却没有效果，优先检查三个点：实际生效的 drop-in 是否覆盖了主文件；/var 是否已经挂载且可写；以及当前 daemon 是否还没有收到 flush 请求。这个顺序比反复重启服务更容易定位原因。

为什么改成 persistent 后还要执行 journalctl --flush

Storage=persistent 解决的是存储策略，但 journald 在启动初期可能已经把消息放在 /run/log/journal。官方对 journalctl --flush 的定义是：在持久化存储可用时，把运行时目录中的日志刷入 /var/log/journal，并等待动作完成。也就是说，“以后写哪里”和“已经写在 /run 的内容搬到哪里”是两个边界。

sudo mkdir -p /var/log/journal
sudo journalctl --flush
journalctl --disk-usage
find /var/log/journal -type f -name '*.journal' -print 2>/dev/null

系统启动时通常由 systemd-journal-flush.service 自动完成这件事，因此正常开机不必每次手动执行。手工创建目录或修改配置后，主动执行一次 flush 更适合做验证。若磁盘仍不可写，persistent 的回退行为仍然成立，不能把一次 flush 没有产生磁盘文件直接解释成命令失败。

另外，SystemMaxUse= 和 RuntimeMaxUse= 只负责容量边界：前者作用于 /var/log/journal，后者作用于 /run/log/journal。它们不会把易失性日志变成持久化日志。

变更后的复查与常见误区

可以把下面的结果作为一次配置复查的最低闭环：

最常见的误区有两个。第一，把“目录存在”当成“配置已生效”；显式的 Storage=volatile 仍然优先。第二，把日志占用超过预期归咎于 SystemMaxUse 没生效；journald 主要删除归档文件，活动文件仍可能暂时保留，所以 vacuum 后的实际占用不一定立刻等于上限。

常见问题

只创建 /var/log/journal，不改 Storage=auto 可以吗？

可以。对默认命名空间，目录存在正是 auto 选择持久化模式的判断条件；改完后再执行 journalctl --flush 复查。

为什么设置 persistent 仍能在 /run 看到 journal 文件？

早期启动、磁盘尚未挂载或暂时不可写时，persistent 允许回退到运行时目录。关键是之后是否成功 flush 到 /var/log/journal。

RuntimeMaxUse 能限制磁盘上的日志吗？

不能。它针对 /run/log/journal；磁盘持久化目录对应 SystemMaxUse 及其相关 System 参数。