journald 占了多少磁盘，怎样设置保留上限

磁盘快满了，发现 /var/log/journal 很大。先确认这是不是主要占用，再决定保留多久。删除日志会损失排障证据，设置未来上限与立即清理旧文件也不是同一件事。

先查 journald 自己报告的用量

journalctl --disk-usage
journalctl --list-boots

第一条显示 journal 文件占用，第二条帮助判断保留了哪些启动周期。它们不是整个 /var/log 的统计；应用自己写出的日志、Docker 日志和下载文件要另查。

journald 可能把持久日志放在 /var/log/journal，运行时日志放在 /run/log/journal。是否持久保存由 Storage 等设置与实际目录条件影响。不要因为机器重启后记录没了，就继续只调整持久日志的限制。

在使用 systemd-journald 的机器上，可以创建 /etc/systemd/journald.conf.d/60-retention.conf：

[Journal]
SystemMaxUse=512M
SystemKeepFree=1G
RuntimeMaxUse=128M

这些数字只是示例。小磁盘、长时间审计和高频日志场景需要不同取值。SystemMaxUse 面向持久文件，RuntimeMaxUse 面向运行时文件；SystemKeepFree 要求给其他用途留空间，但不能替整个磁盘上的所有程序控制写入。

确认当前主配置及其他 drop-in 是否覆盖这些值，保存现状后再按系统的维护流程重启 journald，使配置生效。分离的 journal namespace 还可能有独立配置，不能只查看默认实例。

上限不是所有情况下都能立刻精确压到某个字节数。活动文件、轮转和其他程序占用会影响当时的空间状态，改完仍要重新测量。

确认故障调查所需的记录已经另存后，可以轮转并清理旧归档：

sudo journalctl --rotate --vacuum-size=512M
journalctl --disk-usage

这会删除符合清理条件的旧归档日志，不可逆地丢失那些记录。--rotate 先让活动文件进入归档；vacuum 主要针对归档文件，所以不先轮转时，看到的总用量可能明显高于目标。不要承诺这条命令一定释放多少空间。

如果只需要某项服务近期的日志，可先导出到有权限保护的文件；其中可能包含地址、用户信息或程序输出，保存位置与权限要合适。不要把包含秘密的日志上传到公开粘贴站。

用 journalctl -u 服务名 --since today 检查异常频率。重复失败每秒写一条时，长期缩小保留量会更快抹掉证据，还应修复错误或调低不必要的输出。记录清理前后用量、配置变化与服务状态，下次才能判断限制是否合适。