---
_last_updated_: 2026-06-04T12:00:00+03:00
session_id: 2026-06-04-books-vds-disk-full-remediation
---

# Next session handoff

_Сессия: разбор disk-full алерта Rusonyx на books VDS (89.253.255.133). Причина найдена,
диск 96%→44%, спам-петля заглушена, guard поставлен. Ничего не висит. Вики обновлён + закоммичен (`b0559fdb`)._

## Recent commits

- `b0559fdb` wiki(books-vds): disk-full incident 2026-06-04 + Bookva->slovo job scoping

## Что сделано (books VDS, 04.06)

- ✅ **Диск 96%→44%** (53/122 ГБ). Освобождено ~64 ГБ: обрезаны runaway json-логи
  `books-task-runner` (32.8 ГБ) + `bookva-task-runner` (5.6 ГБ); снесены 11 orphan
  BuildKit-билдеров + 9 `*_state` volumes (~26 ГБ).
- ✅ **Durable guard:** `/etc/logrotate.d/docker-containers` (copytruncate 200M, rotate 3) +
  hourly `/etc/cron.d/docker-logrotate`. Без рестарта докера. crond active, тест-ран чистый.
- ✅ **Root cause:** `books-task-runner` (тенант slovo) error-loop'ил в Ozon по продавцу
  **Bookva (client_id 50542)**, чей `api_key` в `books-db.sellers` **намеренно подменён на
  слововский** (`9683…`) как ревокация доступа books→Bookva-Ozon. Спам шёл из legacy
  seller-перебирающих agenda-джоб без скоупа.
- ✅ **Фикс:** проставлен `data.idSeller=2` (slovo) пяти legacy-джобам в `books-job-scheduler-mongo`
  (`ozon fbs postings syncronization`, `generate old prices`, `ozon fbs products syncronization`,
  `create ozon products in incorrect state report`, `put on sale products`). Залипшие overdue-прогоны
  оборваны (unlock `lockedAt:null` + `docker restart books-task-runner`).
  **Invalid-Api-Key 6448/мин → 0**, джобы отработали по slovo и перепланировались.
- ✅ **Deploy-durable** (user спрашивал): эти джобы legacy (без `data._fromConfig`), reconciler
  (`RECONCILER_ENABLED=true`) трогает только `_fromConfig`-джобы; в `tasks.json` (в образе) у них
  `schedule:null` → пропускает. Эмпирика: `stocks-sync idSeller:2` пережил деплой 31.05.
- ✅ Сверка полноты: 7 seller-перебирающих тасок — все заскоуплены; reconciler-gen джобы уже на
  `salesChannels:[2]`. Группа В снята: Bookva-канал = `type=ym` (Яндекс), Ozon-канала Bookva нет.

## ⚠️ НЕ ДЕЛАТЬ (специфично для этого инцидента)

- **НЕ «чинить» ключ Bookva (50542) в `books-db.sellers`** — он сломан НАМЕРЕННО (подменён на
  слововский) как ревокация. Живой ключ Bookva — в `bookva-db`/конфиге, для тенанта bookva.
  Если снова увидишь `Invalid Api-Key` по 50542 в books-стеке — это не баг ключа, а недо-скоупленная
  джоба. Полный разбор: `.wiki/entities/books-vds.md` § Disk-full incident.

## Follow-up'ы (НЕ блокеры)

| Что | Деталь |
|---|---|
| Каноничный фикс скоупа | legacy seller-джобы стоит перенести в `tasks.json` со скоупом ИЛИ вывести из эксплуатации (возможно, дублируют reconciler-gen). Mongo-правка надёжна, но если релиз даст им `schedule` в tasks.json без скоупа — Bookva-доступ вернётся. → сказать разработчикам books. |
| wiki-drift | `bookva-*` stack + books-task-runner/scheduler не в stack-inventory `books-vds.md`; нужен re-inventory. |
| Native log rotation | daemon.json `max-size`/`max-file` + docker restart — не делал (нужен maintenance window); logrotate-guard покрывает. |

## Открытые треки (.admin — ещё живые)

| Трек | Готовность | Entry-point |
|---|---|---|
| `harden-books-vds-exposed-ports` | ⚪ ready (user сказал «пока нет» на mongo-allowlist) | `.tasks/harden-books-vds-exposed-ports.md` |
| `books-bookva-user-whitelist-gathering` | ⚪ ready — gathering от учредителя | `.tasks/STATUS.md` |
| `stateful-split-volume-copy` / `infra-inventory` | ⚪ ready | `.tasks/STATUS.md` |

## Не делать (preemptive guards)

- **Не возвращать `:9200` / stateful-порты на `0.0.0.0`** без IP-allowlist (books VDS, ransom-бот).
- **Не `ssh + docker compose up -d`** на VDS Portainer-stacks — только Portainer API (искл. traefik/portainer).
- **branch ahead от origin** — push без явного grant'а (Rule 4). Этой сессии grant НЕ давали.

## Memory updates за сессию

- (нет нового файла) — инцидент + корректный root-cause + «не чинить ключ Bookva» зафиксированы
  в `.wiki/entities/books-vds.md` (закоммичено `b0559fdb`).