Журнал systemd: размер, сроки хранения и поиск причины роста

Журнал растёт каждый день, свободное место заканчивается. Ограничить его размер полезно, но сначала стоит посмотреть, кто создаёт поток сообщений: возможно, служба бесконечно перезапускается или пишет одну и ту же ошибку. Разберём команды journald, параметры хранения и разовую очистку старых записей.

Сначала измеряем

journalctl --disk-usage
journalctl -u example.service --since "2 hours ago" --no-pager
df -h /var/log

example.service замените именем своей службы. Сравните время роста с повторяющимися ошибками: отказ подключения, бесконечный перезапуск, слишком подробный режим отладки. Показатель disk-usage включает активные и архивные файлы. Он не равен объёму, который удастся немедленно освободить вакуумированием.

Лимиты хранения journald

# /etc/systemd/journald.conf.d/limits.conf
[Journal]
SystemMaxUse=500M
MaxRetentionSec=14day

Это пример бюджета, а не универсальная норма. SystemMaxUse относится к постоянному журналу; для временного хранения действуют параметры Runtime. Сначала определите, какой режим используется на сервере. Слишком короткая история помешает расследовать сбой, который замечают только в конце недели.

Разовая очистка

sudo journalctl --rotate
sudo journalctl --vacuum-time=14d

Вакуумирование удаляет архивные записи, поэтому перед ним выгрузите нужный интервал в защищённое место. Не обещайте точный итоговый размер: активные файлы и другие ограничения влияют на результат. После изменения конфигурации предусмотрите применение настроек службы journald в согласованное окно.

После настройки снова измерьте размер и убедитесь, что новые сообщения поступают. Затем вернитесь к причине роста: ограничение журнала не исправит бесконечный перезапуск приложения. Запишите выбранные лимиты и зачем они нужны, чтобы позднее их не пришлось подбирать заново.

Источники и дальнейшее чтение

• Debian 11: journalctl
• Debian 11: journald.conf