真正防日志爆盘需配置/etc/systemd/journald.conf中MaxRetentionSec=7d和SystemMaxUse=500M，重启systemd-journald后配合定时journalctl --vacuum-size=400M执行，并验证磁盘用量与时间戳是否符合预期。
直接用 journalctl --vacuum-time 或 journalctl --vacuum-size 就能立刻删掉过期日志，但只执行命令不够——不配策略、不加定时、不验证效果，下次磁盘照样爆。
配置文件里必须设 MaxRetentionSec 和 SystemMaxUse
光靠 vacuum 命令是临时清理，真正防复发得靠 /etc/systemd/journald.conf 里的持久化限制：
-
MaxRetentionSec=7d：不是“自动删除”，而是告诉 journald “超过 7 天的条目可被 vacuum 清理”；不设它，--vacuum-time=7d每次都得手动敲 -
SystemMaxUse=500M：强制所有日志总大小不超过 500MB；否则即使设了时间，空间充足时 journald 会一直攒着不删 -
MaxFileSec=1d和SystemMaxFileSize=100M可加快轮转，让过期判断更及时（尤其在低频写入场景） - 改完必须运行
sudo systemctl restart systemd-journald，否则配置不加载
vacuum 命令要带参数且立刻生效
journalctl --vacuum-* 是唯一安全删数据的方式，它会重建索引、压缩剩余内容，不会损坏 journal 文件结构：
-
sudo journalctl --vacuum-time=7d：删所有早于 7 天的日志（注意：按日志时间戳，不是文件修改时间） -
sudo journalctl --vacuum-size=300M：保留最新压缩后的 300MB，自动淘汰最旧部分 - 两个参数可以一起用：
sudo journalctl --vacuum-size=300M --vacuum-time=7d，journald 按更严格条件执行（取交集） - 执行后马上释放空间，用
journalctl --disk-usage验证，别信“好像变小了”，要看输出数字
crontab 定时跑 vacuum 才算真正自动化
仅靠配置 + 重启服务，不能保证磁盘不爆——journald 不主动触发 vacuum，高负载下可能短暂超限：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 写个脚本
/root/bin/journal-clean.sh，内容就一行：journalctl --vacuum-size=400M > /dev/null 2>&1 - 加到 root 的 crontab：
0 * * * * /root/bin/journal-clean.sh（每小时清一次，比每天更稳妥） - 千万别用
find /var/log/journal -name "*.journal" -mtime +7 -delete或truncate，这些操作会破坏二进制索引，导致journalctl报Invalid argument或直接卡死 - 如果真想手动轮转一次再删，先发信号：
sudo systemctl kill --kill-who=main --signal=SIGUSR2 systemd-journald.service，再 vacuum
验证是否真起作用，别只看配置文件
很多人改完配置就以为万事大吉，结果几天后 df -h 又报警——因为没确认策略是否真正加载、是否实际生效：
- 检查运行时配置：
sudo systemd-analyze cat-config systemd/journald.conf | grep -E "(Retention|MaxFileSec|SystemMaxUse)"，输出必须含你写的值 - 查最早一条日志时间：
journalctl --since "2020-01-01" -n1 --no-pager，和journalctl -n1 --no-pager对比，差值应接近MaxRetentionSec设定 - 连续两天跑
journalctl --disk-usage，看数值是否稳定在SystemMaxUse附近，而不是持续缓慢上涨 - 极端情况下可校验完整性：
journalctl --verify，报错说明索引已损，只能停服务 + vacuum + 重启
最常被忽略的一点：MaxRetentionSec 和 --vacuum-time 依赖系统时间准确。如果服务器时间漂移严重（比如没开 chronyd 或 systemd-timesyncd），日志时间戳会错乱，导致该删的不删、不该删的被删。
