科技 · 实用指南
journalctl 清理释放 0B？先轮转活动日志并解释容量下限
区分活动与归档日志，按持久或易失存储选择容量上限，并验证为何总用量可能仍高于目标。
journalctl 清理成功执行后，仍可能释放 0B，或者让磁盘用量高于指定目标；这不一定表示命令失效。显示的用量包含活动日志文件和归档日志文件，而 vacuum 只删除归档文件。如果这次清理需要涵盖目前为止写入的数据，应先轮转日志。
一次性清理与限制今后的存储用量是两件事。/var/log/journal 下的持久日志使用 System 设置，/run/log/journal 下的易失日志使用 Runtime 设置。即使上限配置正确，活动日志文件和文件大小粒度仍可能使总用量高于名义目标。
1. 删除前记录基线
运行 sudo journalctl --disk-usage 并记录输出。接着检查 sudo du -sh /var/log/journal /run/log/journal 2>/dev/null 和 sudo journalctl --list-boots。第一条命令提供 journal 自身统计的用量；目录检查则帮助确认相关存储是持久、易失，还是两者都有。不要仅凭发行版名称推断存储类型。
清理前，先保存事故调查、审计或支持请求需要的日志。本流程管理本地 journal 存储，不涵盖 journal-remote 的保留策略、导出的归档，或复制到正在使用的 journal 目录层级之外的文件。
2. 修改配置前，先解释 0B 的结果
上游手册说明，--disk-usage 包含活动文件与归档文件，而 vacuum 只处理归档文件。如果存储中只有活动文件，即使设定很小的目标，也可能释放 0B。Server Fault 的案例正是这种情况：后来有了归档文件，清理才释放空间。
不要把 --vacuum-size=0 当作清空快捷方式。当前 systemd 文档规定，0 表示不启用这一限制条件。应选择一个非零目标，并为系统保留足够的诊断历史。
3. 执行有明确范围的一次性清理
若要让清理涵盖目前为止写入的数据，运行 sudo journalctl --rotate --vacuum-size=500M，并把 500M 换成你评估后的目标。组合使用这两个选项，会先轮转活动文件，再清理归档文件。不要在 journald 使用 .journal 文件期间手动删除它们。
再次运行 sudo journalctl --disk-usage，同时记录释放字节数和新的总用量。仍有占用并不自动说明失败：新建的活动文件会保留，其他命名空间或存储也可能贡献用量。
4. 选择与存储类型对应的长期限制
对于 /var/log/journal 下的持久存储，在本地 journald.conf 的 drop-in 配置片段中设置 SystemMaxUse；如果需要更细的删除粒度，再设置 SystemMaxFileSize。对于 /run/log/journal 下的易失存储，应改用 RuntimeMaxUse 和 RuntimeMaxFileSize。SystemKeepFree 与 RuntimeKeepFree 为其他用途保留可用空间；journald 会采用适用限制中较小的那个。
Red Hat 将启用持久日志作为独立过程，并通过确认 /var/log/journal 目录存在且包含文件来验证。对于采用 Storage=auto 的系统，这个目录是否存在会影响存储方式。请遵循所用发行版的配置机制与验证工具，不要直接照抄只适用于某个系统角色的示例。
5. 应用配置并验证
添加本地 drop-in 配置片段后，用发行版提供的工具核对最终生效的配置，按其支持的流程重新加载或重启 systemd-journald，并确认实际使用的存储目录。随后让系统产生普通日志，按需要等待轮转，再检查磁盘用量。配置文件语法正确，也仍可能针对了错误的存储类型。
验证稳定状态，而不只是查看刚完成清理时的结果。记录活动文件大小、归档文件总量、所配置的 MaxUse 与 MaxFileSize，以及剩余可用空间。这有助于区分真实的持续增长，与文档已说明的活动文件下限或较粗的文件大小粒度。
6. 明确结果能够证明什么
一次轮转加清理的结果，只能证明符合条件的本地归档日志文件已被纳入所选条件的检查。它不能证明所有应用日志都由 journald 保存，不能证明远程归档已清理，也不能证明已配置今后的容量上限。
如果用量仍持续超出预期的稳定范围，应收集实际目录、活动与归档文件大小、journal 命名空间、最终生效的配置和 systemd 版本。在证据确定哪个组件消耗空间前，不要反复降低清理目标。
