Debian 系统中，systemd-journald 负责收集内核、服务启动、系统调用等多方日志。它默认会根据 /var/log/journal 目录是否存在来决定持久化策略，一旦该目录被创建，journald 就会把日志以二进制形式持续写入磁盘。很多人遇到根分区突然被写满，第一反应是查业务数据或数据库文件，其实更常见的原因是 journal 日志长期不清理，尤其是运行了数月甚至数年的服务器，/var/log/journal 下可能堆积了数个 GB 的 .journal 文件。
与传统的 /var/log/syslog 文本日志不同，journald 写入的是二进制日志，普通文本工具无法直接阅读，必须借助 journalctl。如果直接使用 rm 命令删除 /var/log/journal 下的文件，journald 可能仍持有文件句柄，导致已删除的空间不会立即释放，甚至破坏正在写入的日志结构。因此，处理 journal 日志占满磁盘的问题，需要先定位、再使用专用清理命令、最后修改配置限制上限，形成完整的处理链条。
快速定位 journal 日志占用
当磁盘空间不足时，先用 df -h 查看根分区使用率，确认是否已经接近 100%。随后执行 journalctl --disk-usage，这条命令会直接输出当前已归档和活动日志占用的磁盘大小，例如 Archived and active journals take up 3.2G on disk. 这个数值如果异常偏高，就能基本锁定是 journald 的问题。
还可以进一步查看 /var/log/journal 目录的体积。使用 du -sh /var/log/journal 可以得到总占用，再用 ls -lh /var/log/journal/*/ 查看具体每个机器 ID 子目录下的日志文件大小。journald 通常会按照日志滚动策略拆分多个 .journal 文件，单文件几十 MB 到几百 MB 不等。如果发现里面存在大量几个月前的旧文件，说明日志保存策略过于宽松。
# 查看根分区使用率 df -h / # 查看 journal 日志磁盘占用 journalctl --disk-usage # 查看 journal 目录总大小 du -sh /var/log/journal # 列出具体文件 ls -lh /var/log/journal/*/
需要注意的是，journald 的日志分为易失存储和持久化存储两种。如果 /var/log/journal 存在，即使 /etc/systemd/journald.conf 中指定 Storage=auto，系统也会选择持久化写入磁盘。如果该目录不存在，日志则写入 /run/log/journal，重启后丢失，不会长期占用磁盘。因此，很多默认安装的 Debian 系统并不会持久化 journal 日志，但某些运维脚本或初始化流程会主动创建 /var/log/journal，从而开启持久化。
使用 vacuum 参数安全清理日志
journalctl 提供了 vacuum 系列参数，专门用于清理旧日志。与直接 rm 不同，vacuum 会通知 journald 释放符合条件的历史文件，并尽量保留当前活跃文件，安全性更高。最常用的是按大小清理，执行 journalctl --vacuum-size=500M 后，journald 会从最旧的日志开始删除，直到归档日志总大小不超过 500M。这个过程通常是秒级的，对正在运行的服务没有明显影响。
如果问题是几天内突然产生大量日志，也可以按时间清理。journalctl --vacuum-time=7d 表示只保留最近 7 天的日志，7 天之前的都会被清除。对于突发性日志暴涨，比如某个服务疯狂刷错，按时间清理往往比按大小更直接。还可以使用 journalctl --vacuum-files=10 限制保留的归档文件数量，适合日志文件数量过多但单文件不大的情况。三个参数可以单独使用，也可以组合使用，例如 journalctl --vacuum-time=14d --vacuum-size=1G。
# 仅保留最近 500M 的归档日志 journalctl --vacuum-size=500M # 仅保留最近 7 天的日志 journalctl --vacuum-time=7d # 仅保留最近 10 个归档文件 journalctl --vacuum-files=10 # 组合使用：保留 14 天且总大小不超过 1G journalctl --vacuum-time=14d --vacuum-size=1G
清理完成后再次执行 journalctl --disk-usage，确认占用已经下降。如果磁盘空间仍紧张，可以检查 /var/log 下的其他大文件，例如 kern.log、syslog、nginx 访问日志等。journald 只管理自身日志，不会清理 syslog 或应用日志，这部分需要交给 logrotate 处理。
修改 journald 配置限制日志上限
临时清理只能解决当前问题，如果不修改配置，journal 日志会再次膨胀。journald 的主配置文件位于 /etc/systemd/journald.conf，编辑它并加入或调整关键参数，可以从根源上限制日志体积。最核心的是 SystemMaxUse，它规定了持久化日志在磁盘上最多可以使用多少空间。比如设置为 SystemMaxUse=500M，journald 会保证 /var/log/journal 的总大小不超过 500M，超出的旧日志会被自动清理。
另一个重要参数是 SystemKeepFree，它表示除了 journal 日志之外，系统磁盘至少需要保留多少空间。假设系统盘为 50G，设置 SystemKeepFree=2G 后，当磁盘剩余空间低于 2G 时，journald 会主动删除旧日志来释放空间。这个参数比单纯限制日志大小更灵活，尤其适合磁盘容量不固定的云服务器。对于内存中的易失日志，RuntimeMaxUse 和 RuntimeKeepFree 分别对应 /run/log/journal 的最大占用和最小保留空间。
[Journal] Storage=auto Compress=yes SystemMaxUse=500M SystemKeepFree=1G RuntimeMaxUse=100M RuntimeKeepFree=200M SystemMaxFileSize=100M MaxRetentionSec=1month
上述配置表示：日志持久化到磁盘，启用压缩，归档日志最大占用 500M，系统磁盘至少保留 1G 空闲，易失日志最大占用 100M，单个归档文件最大 100M，日志最长保留 1 个月。修改配置文件后，需要执行 sudo systemctl restart systemd-journald 让配置生效。重启服务不会删除现有日志，只会影响后续的写入和清理策略，因此建议先执行一次 vacuum 清理，再重启服务观察效果。
如果服务器只是临时测试环境，不需要保留 journal 日志，也可以把 Storage 设置为 volatile。这样日志只会写入 /run/log/journal，重启后自动丢失，几乎不会长期占用磁盘。不过这种方式牺牲了排障能力，生产环境一般不建议完全关闭持久化。更合理的做法是根据服务器日志产生速度，给 SystemMaxUse 设置一个适中的值，例如 200M 到 1G，同时配合 SystemKeepFree 保证磁盘不会写满。
区分 journald 与 logrotate 的职责边界
很多人会把 journald 和 logrotate 混为一谈，认为只要配置了 journald 的压缩和大小限制，所有系统日志都会被管理。实际上，journald 只负责自己写入 /run/log/journal 或 /var/log/journal 的二进制日志。而 /var/log/syslog、/var/log/messages、/var/log/daemon.log 等文本日志通常由 rsyslog 或 syslog-ng 写入，并通过 logrotate 进行轮转压缩。
如果服务器上同时运行着 rsyslog 和 journald，日志就存在两条链路。systemd-journald 从内核和 systemd 服务收集事件，rsyslog 可以读取 journal 并写入传统文本文件。此时即使限制了 journald 的磁盘占用，rsyslog 产生的文本日志仍可能占满磁盘。因此，完整排查磁盘问题时，还需要检查 /etc/logrotate.d/ 下的配置文件，确认 syslog、应用日志的轮转周期和保留数量是否合理。例如 /etc/logrotate.d/rsyslog 中配置了 rotate 7 表示保留 7 份历史文件，如果单个文件过大，仍可能占满磁盘。
对于应用自行写入的日志，比如 nginx 的 access.log、php 的 error.log，journald 完全不会参与管理，必须依靠各自服务的日志轮转规则。常见的做法是在 /etc/logrotate.d/ 下为每个应用创建独立配置，设置 size 触发条件、压缩方式和保留份数。只有把 journald、syslog 以及应用日志三部分都纳入管理，才能避免磁盘空间被日志悄悄耗尽。
journal日志清理Debian磁盘空间logrotate修改时间：2026-08-23 00:15:04