journalctl vacuum 后仍超过容量：清理只作用于归档日志

运行 journalctl --vacuum-size=10M，提示已经删除归档日志，/var/log/journal 的占用却仍超过 10M。先区分活动日志与归档日志：vacuum 清理归档文件，journalctl --disk-usage 的总量则包含两者，因此删除完成后不一定达到你想象的目录总容量。

下面按当前 systemd 的 journalctl 与 journald 行为说明。老系统应先检查本机版本和选项支持，尤其是轮转与清理的组合。清理会删除历史记录，不能在确认保留需求前把它当作无影响的诊断命令。

先确认统计的是同一套日志

只读查看当前 journal 占用：

journalctl --disk-usage

核对当前权限、日志命名空间和读取目录。普通用户可能看不到完整系统日志；容器中的 journalctl 也未必读取宿主机日志。不要把一个环境的清理结果与另一个环境的目录大小直接比较。

文件系统的 du 统计与 journalctl 识别的文件范围可能不同，目录里还可能有其他文件或其他日志实例。应检查实际目录和日志实例，不能只凭“剩下 73M”就断定这 73M 全是活动文件。

清理输出明确写的是 archived journals 时，说明执行对象是归档日志；活动文件仍由 journald 写入。--vacuum-size 不是一个立即约束所有文件的总目录配额，参数设为 0 也不代表删除全部日志，而是不施加这项限制。

需要让已有活动文件参与清理，先轮转

当前 journalctl 支持将 --rotate 与 --vacuum-size 一起使用。轮转先把当前活动文件变为归档，再按容量清理这些归档文件，并为后续日志打开新的活动文件。

下面是保留约 500M 归档日志的操作示例，需要管理权限，并且已经按保留策略导出或备份要保留的故障记录：

sudo journalctl --rotate --vacuum-size=500M

500M 不是适合所有机器的推荐值，应根据审计要求、故障排查窗口和磁盘预算选择。该操作可能清掉别的服务所需的历史日志，不能因为先加了 -u 某个服务名，就假定只会删除该服务的记录；journal 文件里可混合多个服务的日志。

轮转后产生的新活动文件仍占空间，日志也会继续写入，所以目录总量仍可能大于 500M。不要为了强行凑到一个数字反复清理，也不需要先删除正在打开的 .journal 文件。

若本机不支持组合选项，查本机手册确认分别轮转和清理的方式。不能根据新版本示例宣布旧系统命令一定有效，也不应以重启服务器代替正常轮转。

长期限制要配置对应的 journald 实例

一次 vacuum 不会持续执行容量策略。持久日志位于 /var/log/journal 时，核对 SystemMaxUse、SystemKeepFree、SystemMaxFileSize；易失日志位于 /run/log/journal 时，对应的是 Runtime 前缀选项。

SystemMaxUse 规定 journal 使用空间的目标上限，SystemKeepFree 规定给其他用途保留多少空间，journald 会同时考虑二者。单个日志文件大小还决定了轮转后能按多大粒度清理。只降低总预算却忽略活动文件和单文件大小，可能继续看到超过预期的总占用。

下面是持久日志实例的配置片段示例，需合并到对应实例的受控配置中，不能覆盖整份现有设置：

[Journal]
SystemMaxUse=1G
SystemMaxFileSize=128M

这些值只说明配置关系。命名空间日志实例有自己的配置范围，普通 journald 配置不一定改变全部实例。修改前保存有效配置与 drop-in，确认实际存储类型、覆盖顺序和需要重新加载的服务实例。

容量策略同样只删除归档文件，不能保证在任何时刻都严格等于某个总字节数。磁盘被其他程序填满，也不应期待 journald 把所有旧文件无限缩小来替其他程序让空间。

清理后验证保留范围与增长速度

检查操作是否成功、归档文件占用是否下降，以及近期需要的服务日志是否仍可查询。然后观察日志生成速度，定位持续大量写日志的服务；只调大预算或频繁清空不能解释为何增长异常。

长期配置修改可能需要重启相应 journald 实例，应按照该发行版和现有日志流程安排，核对采集连续性。恢复原配置可以恢复以后使用的策略，不能找回已经清理掉的历史记录。需要旧记录时只能从预先保留的备份或外部日志存储恢复。