<p>必须用 journalctl --vacuum-* 清理并修改 /etc/systemd/journald.conf 防复发；快速确认空间用 journalctl --disk-usage，它读取内部元数据最准确，禁用 du -sh 替代。</p>
直接删 /var/log/journal/ 下的文件会破坏索引、导致 journalctl 报错甚至服务写日志失败，必须用 journalctl --vacuum-* 清理，再配合修改 /etc/systemd/journald.conf 防止复发。
怎么快速确认日志占了多少空间
执行 journalctl --disk-usage 是最准的判断方式，它读取 journald 内部元数据，不依赖文件系统统计。输出类似 Archived and active journals take up 3.4G in the file system. 就说明真占了 3.4GB。别用 du -sh /var/log/journal 代替——journald 可能正持有文件锁或未刷盘，du 结果可能滞后或不准。
- 如果提示
No journal files were found.，说明日志没启用持久化，得先检查Storage=配置 - 桌面环境默认常驻内存，但一旦启用了
Storage=persistent，日志就全落盘了 - 某些云主机或容器宿主机可能禁用持久化，此时
--disk-usage永远为 0
用 --vacuum-size 立即释放空间（最常用）
journalctl --vacuum-size=500M 是安全、可逆、见效最快的清理方式。它不是简单删旧文件，而是让 journald 重写索引、压缩归档、只保留最新 500MB 的活跃日志，整个过程原子且不影响正在写入的服务。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 必须加
sudo，否则提示Failed to open journal files: Permission denied - 参数单位支持
K/M/G，不能写成500MB或500mb，否则报错Invalid argument - 可以和
--vacuum-time=7d同时用，journald 会按更严条件执行（比如两者都设，实际只留够 500MB 的最新日志） - 执行后一定再跑一次
journalctl --disk-usage确认结果，别只信终端那句Vacuuming done, freed X.XM
为什么改 journald.conf 才算真正解决问题
临时 --vacuum-* 清完，过几天又涨回几 GB，是因为默认配置不限制上限。关键要改 /etc/systemd/journald.conf 并重启服务：
-
SystemMaxUse=500M：硬性限制整个/var/log/journal/目录最大占用，不是单文件 -
MaxRetentionSec=2week：超期自动删，单位支持7d、1month，别写14 days（空格会失效） -
SystemKeepFree=1G：磁盘剩余不到 1GB 时停止写日志，防系统卡死 - 改完必须运行
sudo systemctl restart systemd-journald，否则配置不加载 - 验证是否生效：
sudo systemd-analyze cat-config systemd/journald.conf | grep -E "(MaxUse|Retention)"
哪些操作绝对不能做
手动删 .journal 文件是最高频的错误操作，后果比想象中严重：
-
rm -f /var/log/journal/*/*.journal会导致journalctl报Invalid argument或部分日志无法读取 -
find /var/log/journal -name "*.journal~" -delete这类“清理备份文件”动作也危险，journald 可能正在用这些临时文件轮转 - 停掉
systemd-journald后rm -rf /var/log/journal再启动，看似清零，但下次服务崩溃或异常重启时，journald 可能拒绝重建目录，或日志丢失 - 用
logrotate对/var/log/journal做切割？完全无效——journald 不识别外部轮转，也不生成文本日志供 logrotate 处理
真正的边界在于：所有对 journal 日志的变更，必须经由 journalctl 或 journald.conf，这是 systemd 设计的强制契约。越界操作看似快，实则埋下静默故障的种子。
