09c815930a
All checks were successful
CI Trade-In / changes (pull_request) Successful in 12s
CI / changes (pull_request) Successful in 12s
CI Trade-In / backend-tests (pull_request) Has been skipped
CI Trade-In / browser-tests (pull_request) Has been skipped
CI Trade-In / frontend-checks (pull_request) Has been skipped
CI / backend-tests (pull_request) Has been skipped
CI / frontend-tests (pull_request) Has been skipped
CI / openapi-codegen-check (pull_request) Has been skipped
Три независимые правки инфраструктурной гигиены прод-VPS, замеренные живьём 2026-08-15 (ssh gendesign, read-only). 1. ops/docker-prune.sh: новая секция снимает зависшие (running, но брошенные) job-контейнеры Forgejo Actions раннера — три штуки Up 4-8 недель на проде, docker container prune их не видит (фильтрует только status=exited). Фильтр по имени — якорь ^FORGEJO-ACTIONS-TASK- (regex, не substring), сервисные контейнеры (forgejo/forgejo-runner*/gendesign-*/tradein-*/couchdb) под него не подпадают + explicit-skip как страховка. Возраст — из docker inspect .State.StartedAt, порог JOB_CONTAINER_MAX_AGE_HOURS (default 24 — CI job столько никогда не идёт). DRY_RUN уже существующий флаг, переиспользован. Идемпотентно на пустом списке (mapfile + `|| true`). 2. ops/journald-gendesign.conf.example: SystemMaxUse=500M для journald. Замер: journalctl --disk-usage без прав группы systemd-journal/adm недосчитывает (показал 174M) — реальный du -sh /var/log/journal = 2.5G, ~80% всех 3.1G /var/log. journald.conf на проде сейчас без лимита вообще. Установка — руками на сервере (systemd-конфиг вне /opt/gendesign, deploy.yml его не синкает): инструкция в шапке файла. 3. Caddyfile: убран мёртвый блок status.gendsgn.ru (указывал на несуществующий uptime-kuma, дёргал ACME раз в 6 часов на staging-эндпоинте). Заодно убрана dangling forward-ссылка "описан для status.gendsgn.ru ниже" в комментарии у meraocenka.ru. grep подтвердил: других ссылок на этот хост в Caddyfile/compose/скриптах не осталось (docker-compose.uptime.yml и README упоминают — вне scope, стек сам по себе не трогается). caddy validate через prod-контейнер (stdin, без записи файлов на диск) — конфиг валиден, как и baseline до правки.
36 lines
2.8 KiB
Text
36 lines
2.8 KiB
Text
# 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
|