# systemd-journald drop-in — cap persistent journal disk usage on prod VPS.
#
# ЗАМЕР 2026-08-15 (ssh gendesign, read-only): `/var/log` занимал 3.1G. Наивная
# первая проверка `journalctl --disk-usage` показала только 174M и навела на
# ложный след «основной объём — не journald». На деле `journalctl --disk-usage`,
# запущенный НЕ из группы systemd-journal/adm, недосчитывает — он не может
# полноценно перечислить архивные *.journal файлы без прав на чтение. Прямой
# `du -sh /var/log/journal` дал 2.5G — это ~80% всего `/var/log`, ровно 100
# файлов по ~48M в /var/log/journal/<machine-id>/. Второй по размеру вклад —
# традиционный rsyslog (syslog/syslog.1/auth.log/kern.log/ufw.log/dmesg/btmp,
# ~0.6G) — те уже ротируются через logrotate (видны .1/.4.gz копии), отдельного
# вмешательства не требуют и вне scope этого файла.
#
# В /etc/systemd/journald.conf на проде НЕТ SystemMaxUse (все ключи закомменчены
# дефолтами) — без явного лимита journald довольствуется default-правилом
# «до 10% файловой системы», на VPS с диском ~145G это фактически безлимит.
#
# УСТАНОВКА НА СЕРВЕРЕ (руками, deploy.yml этот файл НЕ подхватывает —
# systemd-конфиги вне /opt/gendesign, деплой синкает только сам репозиторий):
#   sudo mkdir -p /etc/systemd/journald.conf.d
#   sudo cp /opt/gendesign/ops/journald-gendesign.conf.example \
#       /etc/systemd/journald.conf.d/gendesign-max-use.conf
#   sudo systemctl restart systemd-journald
#
# `restart systemd-journald` применяет лимит немедленно — journald сам
# провакуумит существующие архивные файлы вниз до SystemMaxUse (ожидаемый
# эффект: /var/log/journal схлопнется примерно с 2.5G до ~500M). Это НЕ
# `docker volume rm` / `caddy reload` — под общий deploy-guard не подпадает,
# но всё равно на живом проде: делает user сам после ревью PR.
#
# Значение 500M — консервативный запас на 4 vCPU/4-16G VPS с активным CI
# (docker/forgejo-runner логи в journald тоже льются). При необходимости
# больше retention для дебага — поднять SystemMaxUse, не удалять файл.

[Journal]
SystemMaxUse=500M