Журнал systemd занимает диск: как очистить и ограничить journald

Если журнал systemd занимает много места, проверьте размер командой journalctl --disk-usage, очистите старые записи через journalctl --vacuum-size и задайте постоянный лимит SystemMaxUse в drop-in файле journald. Без настройки journald может занять до 4 ГБ, а шумная служба заполнит этот объём за несколько дней.

Сколько места занимает журнал и почему так много

Начните с точной цифры. Journalctl показывает суммарный размер всех файлов журнала, и активных, и архивных:

journalctl --disk-usage
sudo du -sh /var/log/journal

Если журнал пишется на диск, файлы лежат в /var/log/journal/ID-машины/, если только в память, то в /run/log/journal/. Системный журнал называется system.journal, у каждого пользователя свой user-1000.journal, а архивные файлы получают в имени отметку времени.

Почему он такой большой: journald по умолчанию разрешает себе до 10% размера файловой системы, но не больше 4 ГБ, и следит, чтобы на разделе оставалось 15% свободного места, тоже с потолком 4 ГБ. На диске в 1 ТБ журнал спокойно дорастёт до четырёх гигабайт и будет считать это нормой. Сам по себе такой объём не ошибка, но на корне в 30-40 ГБ или на карте памяти Raspberry Pi он заметен.

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

Очистка журнала одной командой

Удалять файлы из /var/log/journal через rm не нужно. Для этого есть vacuum, и выбрать можно один из трёх критериев:

# оставить не больше 500 МБ
sudo journalctl --vacuum-size=500M
# удалить всё старше двух недель
sudo journalctl --vacuum-time=2weeks
# оставить не больше 5 файлов
sudo journalctl --vacuum-files=5

Тут есть подвох, из-за которого многие думают, что команда не работает. Vacuum удаляет только архивные файлы, текущие активные он не трогает. Если основная часть данных в активном system.journal, размер почти не изменится. Решение - сначала закрыть активные файлы флагом --rotate, а потом чистить, в одной команде:

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

Это разовая уборка. Через неделю журнал снова начнёт расти до старого предела, поэтому дальше нужен постоянный лимит.

Постоянный лимит через drop-in файл

Править сам /etc/systemd/journald.conf можно, но документация systemd советует drop-in файлы: при обновлении пакета основной файл может быть заменён, а ваши настройки в отдельном файле останутся. Создайте каталог и файл:

sudo mkdir -p /etc/systemd/journald.conf.d
sudo nano /etc/systemd/journald.conf.d/50-size.conf

Содержимое для обычного ноутбука или рабочей станции:

[Journal]
SystemMaxUse=500M
SystemKeepFree=2G
MaxRetentionSec=1month

Перезапустите службу журнала и проверьте, что лимит применился. Служба перечитает конфигурацию, записи при этом не теряются:

sudo systemctl restart systemd-journald
journalctl --disk-usage
systemd-analyze cat-config systemd/journald.conf

Последняя команда выводит итоговую конфигурацию со всеми drop-in файлами, так сразу видно, не перебивает ли ваш параметр другой файл. Файлы читаются по алфавиту, для одного и того же параметра побеждает последний.

Сколько ставить

Для домашнего компьютера хватает 200-500 МБ: это недели и месяцы истории. На сервере, где журнал нужен для разбора инцидентов, разумнее 1-2 ГБ и хранение месяц-два, или пересылка в отдельную систему сбора логов. Слишком маленький лимит в 50 МБ мешает: при сбое загрузки нужных записей прошлого запуска может уже не оказаться.

Главные параметры journald.conf

Размеры пишутся с суффиксами K, M, G, T, сроки в формате systemd: 2weeks, 1month, 90d. В старых версиях systemd значение Storage по умолчанию было auto: журнал пишется на диск, только если существует /var/log/journal.

Найти службу, которая засоряет журнал

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

journalctl -b -o json --output-fields=_SYSTEMD_UNIT | jq -r '._SYSTEMD_UNIT // "kernel/other"' | sort | uniq -c | sort -rn | head

Дальше смотрите, что пишет лидер списка, и ищите повторяющиеся ошибки:

journalctl -b -u имя.service -n 50
journalctl -b -p warning

Частые виновники: служба в цикле перезапуска, драйвер Wi-Fi или Bluetooth с потоком предупреждений, ошибки PCIe AER от ядра, приложение в режиме отладки. Как разобрать упавшую службу, описано в статье о поиске упавших служб systemd.

Если исправить источник нельзя, ограничьте конкретную службу, не трогая остальные. Создайте override через sudo systemctl edit имя.service и добавьте:

[Service]
LogLevelMax=warning
LogRateLimitIntervalSec=30s
LogRateLimitBurst=200

LogLevelMax отбрасывает сообщения ниже заданного уровня, а пара параметров rate limit ограничивает поток. После правки выполните sudo systemctl restart имя.service. Подробнее про override и unit-файлы есть в статье про systemctl.

Журнал в памяти и связка с rsyslog

На Raspberry Pi с карточкой microSD или на старом SSD постоянная запись логов лишний раз изнашивает носитель. Можно держать журнал только в памяти, он будет пропадать при перезагрузке:

[Journal]
Storage=volatile
RuntimeMaxUse=64M

Компромисс - оставить persistent, но с маленьким SystemMaxUse. Для домашнего сервера это обычно лучше: после внезапной перезагрузки хочется видеть, что было перед ней. Остальные советы по такой машине собраны в статье про Raspberry Pi как домашний сервер.

Проверить, что после лимита история не пропала

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

journalctl --list-boots
journalctl -b -1 -p err
journalctl -b -1 -e

Первая команда выводит таблицу загрузок с номерами и временем первой и последней записи. -b -1 означает предыдущую загрузку, -p err оставляет только ошибки, а -e сразу прокручивает в конец, к последним секундам перед выключением. Если в списке только одна текущая загрузка, журнал хранится в памяти или лимит слишком мал. Проверьте Storage= и наличие каталога /var/log/journal. После перехода на persistent перенести уже накопленные в памяти записи на диск можно командой sudo journalctl --flush.

Повреждённые файлы и другие странности

После аварийного выключения journald иногда оставляет файлы с тильдой в конце имени, например system@...journal~. Это файлы, которые не удалось корректно закрыть. Проверить целостность можно командой:

sudo journalctl --verify

Файлы с ошибками в выводе помечены как FAIL. Читать из них journalctl обычно может частично, а удалить их безопасно, если старая история не нужна: vacuum тоже уберёт их со временем.

Ещё две ситуации, которые путают с журналом:

• Логи Docker. По умолчанию контейнеры пишут в JSON-файлы в /var/lib/docker/containers/, а не в journald. Их размер ограничивают параметрами log-opts драйвера логирования в /etc/docker/daemon.json.
• Каталог /var/tmp и /tmp. Временные файлы чистятся отдельно через systemd-tmpfiles, к журналу они не относятся. Об этом есть статья про каталог tmp.

Чтобы вернуть настройки по умолчанию, удалите свой drop-in файл и перезапустите systemd-journald. Полное описание параметров есть в man journald.conf.

Частые вопросы

Документация и источники

• journald.conf, systemd / freedesktop.org, 2026
• journalctl, systemd / freedesktop.org, 2026
• systemd.exec: LogLevelMax, LogRateLimitIntervalSec, systemd / freedesktop.org, 2026

Команды проверены на актуальных версиях дистрибутивов на момент обновления. Перед изменением системных настроек сделайте резервную копию.