Лимит журнала journald не сработал: drop-in, SystemKeepFree и архивные файлы решают, сколько места займут логи
Строка SystemMaxUse в конфиге ничего не гарантирует, пока не проверен итоговый конфиг и фактический размер журнала.
Типичная история для своего сервера: диск заполняется, выясняется, что место съел системный журнал. Админ находит в интернете параметр SystemMaxUse, вписывает его, а размер журнала не меняется. Журнал (journal) — это хранилище логов, которое ведёт служба systemd-journald в современных дистрибутивах Linux. Что именно и когда она удаляет, описано в документации journald.conf; ниже — шаги, как выставить лимит и убедиться, что он работает.
Без настройки лимит уже есть, но считается от размера диска
По документации, SystemMaxUse= (сколько места журнал может занять максимум) по умолчанию равен 10% файловой системы, а SystemKeepFree= (сколько места journald оставляет свободным для остальных нужд) — 15%. Каждое из рассчитанных значений ограничено 4G. На небольшом диске это немного, на большом — до четырёх гигабайт, и именно с этим числом стоит сравнивать реальный размер журнала.
Параметры с префиксом System относятся к постоянному журналу в /var/log/journal. Журнал в памяти, в /run/log/journal, регулируют их двойники с префиксом Runtime: RuntimeMaxUse= и RuntimeKeepFree=. Лимит одного вида на другой не влияет.
Лимит нужно положить в drop-in и проверить, что systemd его видит
Drop-in (дополнительный файл, который дополняет основной конфиг, а не заменяет его) читается из /etc/systemd/journald.conf.d/, из файлов *.conf. Файлы сортируются по имени, и для параметров с одним значением побеждает тот, что идёт последним. Файлы в /etc — для локального администратора, и drop-in здесь перекрывает основной конфиг.
После создания файла службу стоит перезапустить: systemctl restart systemd-journald. Затем проверяется итоговая картина. Команда systemd-analyze cat-config работает как systemctl cat, но для конфигов: показывает основной файл и все drop-in'ы.
Если в выводе нет пути с 60-limit.conf и строки SystemMaxUse=500M, лимит не действует: файл лежит не в том каталоге или назван не так. Если строка есть, но значение другое, его перекрыл файл, который идёт в алфавитном порядке позже. Вторая команда показывает сумму по всем журнальным файлам, архивным и активным вместе.
Лимит не обязан дать ровно 500 мегабайт
- SystemKeepFree тоже работает. Он задаёт, сколько места journald оставляет свободным, и если свободного места мало, журнал может занять меньше, чем разрешает SystemMaxUse.
- Удаляются только архивные файлы. Документация journald прямо говорит, что для освобождения места удаляются только архивные файлы, а активные остаются. Поэтому после чистки журнал может занимать больше лимита.
- Размер файла считается от лимита. SystemMaxFileSize= по умолчанию — одна восьмая от SystemMaxUse=, но не больше 128M; при SystemMaxUse=500M это 62,5M на файл (в systemd суффикс M — это мебибайты).
- Возраста лимит не касается. Удаление по времени включает MaxRetentionSec=, по умолчанию там 0, то есть функция выключена.
Освободить место сразу можно вручную, но это удаление насовсем
Ждать, пока journald сам почистит журнал, не обязательно. У journalctl есть ключи --vacuum-size=, --vacuum-time= и --vacuum-files=. --vacuum-size= удаляет самые старые архивные файлы, пока их суммарный размер не упадёт ниже заданного. По документации journalctl, чистка касается только архивных файлов, поэтому сначала просят journald их ротировать: --rotate архивирует активные файлы, и чистка видит все данные.
Запускать её стоит от root или через sudo. Удалённые записи не вернуть, поэтому перед запуском стоит посмотреть journalctl --disk-usage и убедиться, что нужные для расследования логи уже выгружены в другое место. Разовую чистку стоит считать аварийной мерой, а постоянный потолок держать в drop-in.
Что проверить у себя
- Проверить, что systemd-analyze cat-config systemd/journald.conf показывает файл с лимитом и нужное значение.
- Сравнить journalctl --disk-usage с потолком: если лимит не задан, SystemMaxUse= равен 10% диска, SystemKeepFree= — 15%, оба не больше 4G, и действует меньшее из двух.
- Убедиться, что журнал лежит там, где ожидается: /var/log/journal для постоянного, /run/log/journal для журнала в памяти, и лимит выставлен для нужного.
- Если логи нужны для расследований, решить, сколько дней хранить, и выставить MaxRetentionSec= отдельно: по умолчанию он выключен.
- Перед ручной чисткой убедиться, что важные логи уже скопированы в другое место.
- Добавить в мониторинг свободное место на разделе с /var: лимит журнала не спасёт, если место съедает что-то другое.
Разборы аварий и практику для админов публикуем в Telegram-канале «Полный Ops».