永久限制journald日志必须修改/etc/systemd/journald.conf并重启服务，关键参数为SystemMaxUse、SystemMaxFileSize和MaxRetentionSec，配合Storage=persistent启用持久化存储。
直接改 journald.conf 才算真正生效
只用 journalctl --vacuum-size 是临时清理，重启后照常涨。永久限制必须编辑 /etc/systemd/journald.conf，否则所有策略都是纸面功夫。
关键参数只有三个要动：
-
SystemMaxUse=500M：总空间上限，推荐 200M–1G，小内存服务器别设超 500M -
SystemMaxFileSize=100M：单个日志文件最大体积，避免 vacuum 扫描太慢 -
SystemKeepFree=500M（可选）：强制保留至少 500MB 空闲空间，防写满根分区
改完必须执行 sudo systemctl restart systemd-journald，不重启等于没改。验证用 journalctl --disk-usage，看到 “Archived and active journals take up X in the file system” 才算落地。
MaxRetentionSec 和 SystemMaxUse 必须配合用
光设时间不设大小，高频率日志（比如频繁崩溃的服务）几天就能撑爆磁盘；光设大小不设时间，低频系统可能几年只存几十 MB，但日志碎片多、查询慢。
典型组合示例：
-
MaxRetentionSec=4week：日志最长存 4 周，超时自动轮转淘汰（注意：不是立刻删，得靠 vacuum 触发） -
SystemMaxUse=500M：同时卡死总容量，双保险 -
MaxFileSec=1week：让单个日志文件最多活 7 天，加速轮转节奏
这三项在同一个 [Journal] 段落里配置，顺序无关，但缺一不可。
别手动删 .journal 文件
/var/log/journal/*/system.journal 这些是二进制索引文件，直接 rm 可能导致 journalctl 报错或跳过部分日志。
正确做法只有两种：
- 用
journalctl --vacuum-size=400M或--vacuum-time=14d主动触发清理 - 依赖配置生效后，journald 在下次轮转时自动归档+压缩+丢弃旧块
如果已经误删，重启 systemd-journald 后它会重建索引，但丢失的日志无法恢复。
定时 vacuum 是最后一道防线
即使配置了 SystemMaxUse，journald 在高负载下仍可能短暂超限——因为 vacuum 不是实时触发的。
建议加 crontab 每小时兜底一次：
- 新建脚本
/root/bin/journal-clean.sh，内容为：#!/bin/bash journalctl --vacuum-size=450M > /dev/null 2>&1 - 加定时任务：
0 * * * * /root/bin/journal-clean.sh - 记得给脚本加执行权限：
chmod +x /root/bin/journal-clean.sh
这个脚本只在当前日志超 450M 时才实际删，低于就不动，安全又省心。
最容易被忽略的是 Storage=persistent 这一行——如果没设，日志默认写进 /run/log/journal（内存 tmpfs），重启就丢，SystemMaxUse 对它完全无效。确认是否持久化，先看 journalctl --disk-usage 输出路径是不是 /var/log/journal。
