journalctl 找不到上次启动日志：检查 journald 是否只写入 /run

服务器重启后，journalctl -b -1 返回无法找到上一次启动，当前启动的日志却正常。先检查日志是否持久保存。若之前只写在 /run/log/journal，重启后这部分日志通常已经丢失，事后开启磁盘保存不能把它恢复。

本文适用于系统默认 journal 命名空间。下面的 --flush 操作需要 systemd 217 及以上；较旧版本应按本机提供的选项处理，不照搬现代命令。日志为空也可能与读取权限、保留策略或过滤条件有关，不能只凭一条错误就认定存储模式。

先排除权限和过滤条件

在有权限的受控终端检查启动列表和上一轮日志：

sudo journalctl --list-boots
sudo journalctl -b -1 --no-pager
sudo journalctl --disk-usage
ls -ld /var/log/journal /run/log/journal

--list-boots 显示可访问日志中实际包含的启动，不是主机全部重启历史。普通用户看不到记录而管理员能看到，应先处理必要的日志读取权限，不能把敏感日志目录改成任意用户可读。

管理员也只有当前启动记录时，再查看 /etc/systemd/journald.conf 及其覆盖目录，确认实际配置，没有被后面的同名设置覆盖。不同发行版、安装镜像和版本可能采用不同默认值。

auto、volatile、persistent 的区别

Storage=volatile 使用 /run/log/journal，这类临时存储不适合依赖它追踪重启前的故障。

Storage=auto 会根据 /var/log/journal 是否存在决定是否使用持久目录。如果该目录之前没有创建，即使配置写着 auto，也可能只保留当前启动。

Storage=persistent 优先写入 /var/log/journal，但启动早期或磁盘不可写时仍可能暂用 /run。因此仅看到配置里是 persistent，不能证明磁盘保存已经正常。

同时要注意 Storage=none、独立命名空间，以及磁盘上限、保留时间、日志清理与机器标识变化。日志位于磁盘但已经被清理的情况，与从未写入磁盘的处理不同。

已确认 auto 且缺少持久目录时

确认有足够磁盘空间、确实需要保留系统日志，且没有禁止持久存储的上层运维要求后，可创建目录并让发行版的 tmpfiles 规则设置所需属组、模式和 ACL：

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

这些操作会开始使用磁盘空间；不要用随手指定的宽松权限代替发行版规则。--flush 要求持久存储条件已经成立，用于将当前运行时的 journal 切换或写入持久目录，不需要为了这个 auto 分支先重启服务器。

如果配置明确为 volatile，单独创建目录不够，需要按本机版本调整 journald 配置，并用受支持的方式使它生效。更改前备份主配置和覆盖文件，在维护窗口按发行版要求重启日志服务，再核对 flush 与磁盘日志。不要先停止日志服务或直接删除现有 journal，旧版本及不同日志流连接方式的影响应单独核对。

设置持久保存后，还应给日志安排与磁盘容量匹配的空间上限和保留要求。增加持久目录并不保证日志永远保存；故障记录需要长期留存时，用单独的归档或远程采集承接。

这次能验证保存，下一次正常重启才能验证跨启动读取

当前可检查 /var/log/journal 下是否形成有效日志，以及 journald 是否报告写盘错误。--flush 返回成功，不表示之前丢失的启动记录重新出现。

等下一次已有计划的正常重启后，再查看启动列表和 -b -1；不为验收这一配置而临时重启生产服务器。修正成功应能读到此前已写入并仍在保留范围内的上一轮启动记录。

需要回退存储策略时恢复本次配置，按本机要求生效。既有磁盘日志不会因为改成 volatile 自动被清除；如果必须撤销目录创建，先归档日志、核对 journald 不再使用该目录，再按维护流程处理，不能直接把日志目录当作临时文件删掉。