fix(orchestrator): закрыть два остатка на стыке guard и замка операций

Оба дефекта — в механизмах, введённых предыдущими коммитами, и оба относятся к гарантиям, ради которых эти механизмы вводились. 1. Отказ записи `auto-rollback-fired` оставался незамеченным. Инвариант фиксации "маркера нет и юниты inactive => guard не сработал" верен только при дополнительном условии "guard способен записать маркер". Пока `rc=0` стояло ПОСЛЕ создания маркера, отказ записи (заполненный tmpfs /run, read-only ФС) не влиял ни на что: скрипт успешно восстанавливал прежний firewall, завершался кодом 0, юнит уходил в inactive, маркера не было — и операция фиксировала успех после реально сработавшего отката. `rc` объявляется до первой операции, включая создание маркера, а ранний выход возвращает его вместо жёсткого `exit 0`. У факта срабатывания появилось два независимых канала: маркер и отказ юнита, потому что на пути фиксации успеха допустим ровно один ActiveState — inactive. Заодно маркер создаётся `touch`, а не `: >file`: двоеточие — special builtin POSIX, ошибка перенаправления на нём обязана завершить неинтерактивный shell целиком, и в dash скрипт умер бы ДО восстановления firewall. 2. Новая операция могла начаться, пока guard предыдущей ещё вооружён. Замок действует, пока жив процесс-держатель. Guard — отдельный объект systemd, переживающий свой процесс: A берёт замок -> применяет firewall -> вооружает guard на 45s A аварийно умирает B берёт замок и начинает менять production paths guard A срабатывает и возвращает firewall, который был ДО A Случай SIGTERM/SIGHUP хуже, чем kill -9: обработчик снимает замок сам, поэтому проверка живости держателя не видит вообще ничего, а таймер остаётся. Введён барьер покоя `assertNoPendingRollbackGuard`, через который проходит каждый захват замка — дважды, до и после, потому что между ними умирающая операция успевает вооружить guard, — и PHASE 0 установщика. Непокоем считаются active/activating/deactivating/reloading; `failed` и `inactive` — покой, иначе барьер блокировал бы `repair`, которым чинят последствия. Плюс P1: восстановление UnitFileState у nftables.service больше не обещает точности, которой не даёт. `enable --runtime` не удаляет постоянную ссылку, поэтому "восстановление" enabled-runtime оставляло юнит включённым в обоих scope. Восстанавливаются enabled/disabled — то, что операция реально меняет, — остальные состояния называются оператору и не трогаются. Тесты: поведенческая проверка раннего пути rollback-скрипта настоящим shell (ветка заканчивается до первой команды восстановления и безопасна для запуска), проверка двойного вызова барьера и снятия замка при его отказе, структурные инварианты. Приёмка и docs (D1h, уточнение D1f) — там же.
2026-08-31 03:30:14 +05:00
parent 0230f1ca99
commit 76d78ac71f
12 changed files with 820 additions and 30 deletions
@@ -161,6 +161,22 @@ SIGTERM от systemd и при обрыве SSH. Если процесс был
 operation lock … is held by install (pid 1234), which is no longer running; reclaiming it
 ```

+**Замка при этом недостаточно, и это важно.** Он действует, пока жив
+процесс-держатель, а rollback guard firewall — отдельный объект systemd,
+переживающий свой процесс. Аварийно умершая операция оставляет guard
+вооружённым, и он способен вернуть прежний firewall уже посреди следующей
+операции. Поэтому каждый захват замка проходит ещё и через барьер покоя:
+
+```text
+previous HY2XS operation is no longer running, but its firewall rollback guard
+is still armed: hy2xs-fw-rollback-<op-id>.timer (active)
+```
+
+Условие старта — не «PID предыдущей мёртв», а «у предыдущей не осталось
+исполнителей, способных изменить систему». Ждать нужно не больше 45 секунд с
+момента применения firewall; `failed` у guard покою не мешает и означает, что
+пора смотреть `journalctl -u 'hy2xs-fw-rollback-*'` и запускать `repair`.
+
 `/run/lock` — это tmpfs, поэтому перезагрузка снимает замок в любом случае.
 Удалять файл руками нужно только если в нём оказалось непонятное содержимое:
 такой замок сознательно не переиспользуется автоматически — непонятый файл не