journalctl --vacuum-time=1d 只删除时间早于1天的归档日志文件（如.journal~或.journal.gz），不处理当前活跃的system.journal文件，因其按文件粒度清理而非日志条目时间；需配合SystemMaxUse和MaxFileSec配置及SIGUSR1重载才能有效控量。
为什么 --vacuum-time=1d 不清理所有日志文件
journalctl --vacuum-time=1d 只影响「已归档」的日志文件（即被轮转、压缩或标记为不可写入的 .journal~ 或 .journal.gz），而当前正在写入的活跃日志文件（system.journal）不会被删除，哪怕它包含几天前的日志。这是因为 journald 采用内存+磁盘混合缓冲策略，旧条目在运行中不会被实时剔除，只会在下次轮转或触发 vacuum 时按文件粒度裁剪。
常见错误现象：执行后 /var/log/journal/ 下磁盘占用几乎不变；du -sh /var/log/journal/* 显示单个 system.journal 文件仍达数 GB。
- 该命令不强制滚动当前日志，也不重写活跃文件内容
- 它只删除「时间戳早于 1 天前」的完整日志文件，而非按日志条目时间过滤
- 若系统长期未重启、也未触发自动轮转（如
SystemMaxUse未超限），就只有一个大文件持续增长
必须配合 SystemMaxUse 和 MaxFileSec 才能控制碎片与体积
journald 的“碎片”本质是未轮转的大文件 + 大量小归档文件混存。仅靠 vacuum 命令无法解决根本问题，需在 /etc/systemd/journald.conf 中设置主动约束：
-
SystemMaxUse=500M：限制整个/var/log/journal/目录最大用量，超限时自动删除最老文件（包括活跃文件的旧部分） -
MaxFileSec=1day：强制每 24 小时滚动一次日志文件，避免单文件无限膨胀 -
Storage=persistent（确保日志落盘，否则volatile模式下重启即丢，vacuum 无意义）
改完配置后必须执行 sudo systemctl kill --signal=SIGUSR1 --kill-who=main systemd-journald 触发重载（不能只用 systemctl restart systemd-journald，后者会中断日志写入）。
journalctl --vacuum-size 比 --vacuum-time 更适合控盘
当磁盘空间紧张且需要快速释放时，--vacuum-size 是更直接有效的手段——它按总大小裁剪，无视时间，优先删最老的完整文件，直到剩余空间满足要求：
-
journalctl --vacuum-size=200M：保留最新日志，使整个 journal 目录 ≤ 200MB - 比
--vacuum-time更可靠，尤其适用于日志写入不规律、或时间戳被篡改的环境 - 注意：该操作仍不触碰当前活跃文件的内部碎片，但配合
MaxFileSec后，下次轮转就会生成更小的新文件
可加入定时任务：0 3 * * * journalctl --vacuum-size=300M &>/dev/null，每天凌晨清理到 300MB 内。
真正释放磁盘空间前，别忘了 fstrim 或 sync && echo 3 > /proc/sys/vm/drop_caches
即使 journal 文件被删除，ext4/xfs 等文件系统可能因延迟分配或缓存机制，不立即向块设备报告空间可用。特别是使用 SSD 或 LVM 的场景，常出现 df 不更新、du 已变小但磁盘仍报满：
- SSD 用户建议运行
sudo fstrim -v /（需启用 discard mount 选项或定期执行） - 普通磁盘可先
sync刷盘，再echo 3 > /proc/sys/vm/drop_caches清页缓存（仅临时生效，不影响数据） - 极端情况下，
journalctl --rotate强制滚动 +--vacuum-size组合使用，比单次 vacuum 更彻底
活跃日志文件的内部结构无法被 vacuum 拆解，它的“碎片”不是传统意义的磁盘碎片，而是未压缩的二进制索引+数据混合体——这点最容易被忽略。
