systemd journal 占用过大时，先用 journalctl --disk-usage 确认用量，再按保留需求清理归档日志，并通过 journald 配置控制后续增长。活动日志也计入总量，因此清理后不一定立即低于指定值。

适用范围与验证状态

本文面向运行 systemd-journald 的 Linux 主机，命令流程按 systemd 227 及以上的功能编写，参考 systemd 247 和当前官方手册。发行版可能有默认配置差异，请先检查本机版本。本文为 AI 辅助的官方资料整理，未在目标主机实测；500M、100M 和 1G 都是示例值，不是通用容量建议。

一、确认占用来自 journal

journalctl --version
systemctl is-active systemd-journald
sudo journalctl --disk-usage

先记录总用量。不要仅凭根分区空间不足就删除日志目录；若 journal 本身占用不大，应继续排查其他目录。--disk-usage 统计活动文件与归档文件，相关定义见 journalctl 官方手册。

二、按保留需求清理归档

下面的 vacuum 操作会永久删除匹配的历史 journal 文件。如果日志仍用于故障排查、审计或事件留存，请先按既定流程归档，并确认保留周期。不要把清理目录中的全部文件作为默认方案。

只按归档占用清理，可先执行：

sudo journalctl --vacuum-size=500M

如果希望将当前活动文件先轮转为归档，再纳入清理，可改用下面这一条；它可能删除刚轮转文件中的历史记录，应先确认可以接受：

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

vacuum 只处理归档文件；rotate 会开启新的活动文件。总用量包含新活动文件，所以不要把 500M 理解为运行后总占用必然精确小于 500M。两者语义见 官方清理与轮转说明。

三、为后续增长设置上限

一次清理不能代替长期容量策略。官方支持在 /etc/systemd/journald.conf.d/ 放置本地覆盖配置；如已有同名文件，先备份，不要直接覆盖。用编辑器创建 80-local-size.conf，示例如下：

[Journal]
SystemMaxUse=500M
SystemKeepFree=1G
RuntimeMaxUse=100M

SystemMaxUse 面向持久日志，RuntimeMaxUse 面向运行时日志；保留空闲空间与用量上限共同约束 journal。此配置不会把易失存储自动改为持久存储，也不会保证整个磁盘始终有 1G 空闲。目录、优先级和选项解释见 journald.conf 官方文档。

确认配置语法、保留要求和现有覆盖文件后，通过服务重启应用配置。使用 restart，不要拆成手工 stop 后再 start；journal 服务对日志流的处理参见 systemd-journald 服务文档。

sudo systemctl restart systemd-journald

四、验证结果与排查后续增长

systemctl is-active systemd-journald
sudo journalctl --disk-usage
sudo journalctl -u systemd-journald -n 30 --no-pager
  1. 确认服务仍为 active；如有配置报错，按错误信息检查覆盖文件并恢复原配置。
  2. 与清理前记录对比，确认用量变化；不要伪造或预期固定的“节省百分比”。
  3. 隔一段正常业务运行时间再次检查。若用量快速增长，选取实际应用的服务单元查看近期日志，排查反复报错或过量调试输出，而不只是持续加大容量上限。

撤销自定义容量策略时，恢复备份，或将本次新增文件移出 *.conf 加载范围后重新应用；这不能恢复已被 vacuum 删除的历史日志。

常见误区

  • 清理后仍超出目标：先区分活动与归档文件，再核对是否查看了同一主机和权限范围。
  • 配置了 SystemMaxUse 仍在增长：核对实际存储位置、其他覆盖文件和运行时日志限制；容量控制也不等于立即回收所有现有占用。
  • 查不到 journal 服务：精简容器或其他日志方案未必运行 journald，不能直接套用本文。

相关阅读