唯一可靠方式是修改 /etc/systemd/journald.conf 中的 SystemMaxUse 并重启 systemd-journald 服务；journalctl --vacuum-size 仅为一次性清理命令，无法自动持续限制日志总量，不重启服务则配置不生效，且 ForwardToSyslog=yes 时 rsyslog 日志不受此控制。
直接改 /etc/systemd/journald.conf 里的 SystemMaxUse，然后重启 systemd-journald 服务 —— 这是控制 systemd 日志总大小的唯一可靠方式。
为什么不能只靠 journalctl --vacuum-size？
这个命令是一次性清理动作，不是“自动”策略。它执行完就结束，下次日志继续增长，除非你手动再跑或写进 cron。真正自动限制大小，必须靠配置文件固化规则。
-
journalctl --vacuum-size=100M只会立刻删旧日志，让当前总占用 ≤100MB，但之后仍可能涨到 500MB 才触发下一次清理（如果没配自动策略） - 系统重启、服务重载、甚至 journal 文件损坏后重建，都依赖
journald.conf的设定来约束初始行为 - 不改配置，仅靠定时脚本调用
--vacuum-size，容易因权限、路径或服务未就绪导致失败
SystemMaxUse 和 SystemMaxFileSize 的区别
这两个参数作用不同，别混用：
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
-
SystemMaxUse：限制整个/var/log/journal/目录下所有 journal 文件的**总磁盘占用**（例如设为200M，就是最多存 200MB 的日志） -
SystemMaxFileSize：限制**单个 journal 文件**的最大大小（默认约 100MB，超过就自动切新文件），不影响总量 - 真正管“自动清理大小”的是
SystemMaxUse；SystemMaxFileSize只影响文件切分粒度，和总量无关
修改后必须重启服务才生效
改完配置不重启，systemd-journald 不会读新值。常见错误是改了 conf 就以为完事了：
- 编辑配置：
sudo vi /etc/systemd/journald.conf - 取消注释并修改行：
SystemMaxUse=100M（注意单位必须带 M/G，不能写 100m 或 100） - 保存后执行：
sudo systemctl restart systemd-journald - 验证是否生效：
journalctl --disk-usage看当前占用，再等几小时观察是否被压到设定值以下 - 顺带检查状态：
sudo systemctl status systemd-journald，确认没有 failed 或 warning
别忽略 ForwardToSyslog 对磁盘的实际影响
即使把 SystemMaxUse 设得很小，如果同时开启 ForwardToSyslog=yes（默认是 yes），journald 会把日志实时转发给 rsyslog，而 rsyslog 写的 /var/log/messages 等文件不受 journald 配置控制 —— 它们由 logrotate 管理。
- 如果你发现
/var/log/journal/占用很小，但/var/log/下其他日志爆满，问题不在 journald，而在 rsyslog + logrotate - 想彻底减负，可关掉转发：
ForwardToSyslog=no，再重启systemd-journald和rsyslog - 但关掉后，
journalctl是唯一查日志途径，/var/log/messages将不再更新 —— 这点必须提前评估运维习惯
真正起效的自动清理，靠的是配置固化 + 服务重启。临时命令、cron 脚本、手动 truncate，都是补救手段，不是自动策略。最容易被忽略的是：改完 journald.conf 忘记重启服务，或者没意识到 rsyslog 日志是另一套体系。
