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) — там же.
This commit is contained in:
@@ -135,6 +135,13 @@ smoke: smoke на медленном, но исправном сервере м
|
||||
systemd, `stop` возвращает 5, и этот исход неотличим от успешного снятия
|
||||
взведённого таймера.
|
||||
|
||||
У факта срабатывания два независимых канала, и это не избыточность. Маркер —
|
||||
обычный. Отказ юнита — аварийный: если записать маркер не удалось (заполненный
|
||||
tmpfs `/run`, read-only ФС), скрипт поднимает код возврата, юнит уходит в
|
||||
`failed`, а `failed` на пути фиксации успеха запрещён так же, как и маркер.
|
||||
Без второго канала инвариант был бы верен лишь при дополнительном условии
|
||||
«guard способен записать маркер», которого никто не гарантирует.
|
||||
|
||||
Сам rollback-скрипт восстанавливает файлы и ruleset, накапливает код возврата и
|
||||
уходит в `failed` при частичном восстановлении. Состояние `nftables.service` он
|
||||
сознательно не трогает: у этого юнита `ExecStop=/usr/sbin/nft flush ruleset`, то
|
||||
@@ -142,6 +149,27 @@ systemd, `stop` возвращает 5, и этот исход неотличи
|
||||
active восстанавливает обычный откат в процессе оркестратора, где порядок стадий
|
||||
контролируется.
|
||||
|
||||
### Guard переживает свой процесс
|
||||
|
||||
Guard — объект systemd, а не часть процесса оркестратора. Аварийно умершая
|
||||
операция оставляет его вооружённым, и он способен вернуть прежний firewall уже
|
||||
посреди **следующей** операции. Замок операций от этого не защищает: он
|
||||
действует, пока жив процесс-держатель.
|
||||
|
||||
Поэтому условие начала новой операции — не «PID предыдущей мёртв», а «у
|
||||
предыдущей не осталось исполнителей, способных изменить систему». Каждый захват
|
||||
замка проходит через барьер покоя: если хоть один `hy2xs-fw-rollback-*` находится
|
||||
в состоянии `active`, `activating`, `deactivating` или `reloading`, операция
|
||||
отказывает.
|
||||
|
||||
`inactive` и `failed` считаются покоем: отработавший guard больше ничего не
|
||||
сделает, а отказ по `failed` заблокировал бы `repair` — ровно тот инструмент,
|
||||
которым чинят последствия.
|
||||
|
||||
Состояния `hysteria-server`, `hy2xs-admin` и `nftables.service` барьер
|
||||
сознательно не проверяет: незавершённый `systemctl restart` ничего не
|
||||
откатывает, он лишь повторяет то, что новая операция сделает сама.
|
||||
|
||||
### Проверка эффективного firewall
|
||||
|
||||
`nft -c -f /etc/nftables.conf` разбирает текущий файл, каким бы он ни был, и
|
||||
|
||||
@@ -257,6 +257,18 @@ HYSTERIA_BIN=/usr/local/bin/hysteria ./tools/test/e2e-hysteria.sh
|
||||
- скрипт не маскирует ошибки (`|| true`, `2>/dev/null`), не использует `set -e`
|
||||
и возвращает накопленный `rc`: каждый сообщённый отказ поднимает код возврата,
|
||||
поэтому частичное восстановление уходит в `failed`, а не в молчаливый `0`;
|
||||
- `rc` объявляется **до** создания маркера, а ранний выход возвращает его, а не
|
||||
жёсткий `0`. Инвариант фиксации верен только при условии «guard способен
|
||||
записать маркер»: пока `rc=0` стояло после, отказ записи (заполненный tmpfs
|
||||
`/run`, read-only ФС) не влиял ни на что — скрипт восстанавливал прежний
|
||||
firewall, завершался нулём, и операция фиксировала успех после реально
|
||||
сработавшего отката. Теперь у факта два канала: маркер и отказ юнита;
|
||||
- маркер создаётся `touch`, а не `: >file`: двоеточие — special builtin POSIX,
|
||||
и ошибка перенаправления на нём обязана завершить неинтерактивный shell
|
||||
целиком, то есть в dash скрипт умер бы **до** восстановления firewall;
|
||||
- поведенчески проверяется ранний путь скрипта — он заканчивается до первой
|
||||
команды восстановления и потому безопасен для запуска: при доступном каталоге
|
||||
маркер создаётся и выход нулевой, при недоступном — выход ненулевой;
|
||||
- скрипт не трогает `nftables.service`: у него `ExecStop=nft flush ruleset`, и
|
||||
остановка сервиса стёрла бы только что восстановленные правила;
|
||||
- скрипт разбирается **настоящим** shell-парсером. Парсер принимается только
|
||||
@@ -294,6 +306,10 @@ HYSTERIA_BIN=/usr/local/bin/hysteria ./tools/test/e2e-hysteria.sh
|
||||
- захват под read-only guard отказывает, наблюдение — разрешено. Замок берётся
|
||||
до включения guard, и проверка существует, чтобы перенос захвата внутрь
|
||||
читающей фазы отказал громко, а не записал файл молча;
|
||||
- барьер покоя вызывается **дважды** — до захвата и уже под замком, — а отказ
|
||||
второй проверки снимает замок за собой. Замок сам по себе гарантии не даёт:
|
||||
он защищает production paths, пока жив держатель, а rollback guard переживает
|
||||
свой процесс;
|
||||
- политика CLI закреплена структурно: `install`/`reconfigure`/`repair`/`doctor`
|
||||
вызываются только под замком, `status`/`diagnostics` его не берут, но сообщают
|
||||
об идущей операции, а `preflight-install` отказывает до собственных проверок.
|
||||
@@ -1083,14 +1099,61 @@ reconfigure идёт -> diagnostics collect
|
||||
→ в stderr есть note об идущей операции
|
||||
```
|
||||
|
||||
Отдельно проверяется, что замок не переживает своего держателя:
|
||||
Отдельно проверяется, что замок не переживает своего держателя. **Важно:**
|
||||
прерывать операцию нужно ДО шага `firewall`, иначе проверяется уже сценарий
|
||||
D1h, а не этот.
|
||||
|
||||
1. `reconfigure --apply` прерывается `Ctrl+C` — замок снят, следующий
|
||||
`reconfigure` проходит;
|
||||
2. процесс убивается `kill -9`, после чего следующая операция сообщает
|
||||
`is held by … which is no longer running; reclaiming it` и продолжает;
|
||||
1. `reconfigure --apply` прерывается `Ctrl+C` на шаге `config generation` —
|
||||
замок снят, следующий `reconfigure` проходит;
|
||||
2. процесс убивается `kill -9` на том же шаге, после чего следующая операция
|
||||
сообщает `is held by … which is no longer running; reclaiming it` и
|
||||
продолжает;
|
||||
3. `/run/lock/hy2xs-orchestrator.lock` не остаётся после завершения операции.
|
||||
|
||||
## D1h. Аварийно умершая операция с вооружённым guard
|
||||
|
||||
Проверяется на рабочей установке. Это стык двух защитных механизмов, и до его
|
||||
закрытия каждый из них по отдельности работал правильно, а вместе они
|
||||
оставляли дыру.
|
||||
|
||||
Замок защищает production paths, пока **жив процесс-держатель**. Rollback guard
|
||||
firewall — отдельный systemd-объект, который свой процесс переживает. Поэтому:
|
||||
|
||||
```text
|
||||
A берёт замок -> применяет firewall -> вооружает guard на 45 секунд
|
||||
A аварийно умирает
|
||||
B берёт замок (снятый обработчиком сигнала либо переиспользованный)
|
||||
B начинает менять production paths
|
||||
guard A срабатывает и возвращает firewall, который был ДО A
|
||||
```
|
||||
|
||||
Уникальные `op-id` здесь не помогают: каталоги копий разные, а
|
||||
`/etc/nftables.conf`, `/etc/nftables.d/hy2xs.nft` и ruleset в ядре — общие.
|
||||
|
||||
Сценарий:
|
||||
|
||||
1. `reconfigure --apply` доводится до появления в журнале
|
||||
`firewall rollback guard armed`;
|
||||
2. процесс убивается `kill -9` (замок остаётся устаревшим) — и, отдельным
|
||||
прогоном, `kill -TERM` (замок снимается обработчиком, то есть его вообще не
|
||||
будет; это и есть случай, который проверка живости держателя не ловит);
|
||||
3. **до истечения 45 секунд** запускается `repair` или `reconfigure --apply`;
|
||||
4. новая операция обязана отказать:
|
||||
|
||||
```text
|
||||
previous HY2XS operation is no longer running, but its firewall rollback guard
|
||||
is still armed: hy2xs-fw-rollback-<op-id>.timer (active)
|
||||
```
|
||||
|
||||
5. отказ происходит **до** снятия резервной копии и до первой мутации;
|
||||
6. `install.sh` в том же окне отказывает на PHASE 0 по той же причине;
|
||||
7. после срабатывания guard (`hy2xs-fw-rollback-*` больше не `active`)
|
||||
`repair` проходит.
|
||||
|
||||
Обратная проверка: на сервере без вооружённого guard барьер молчит и ни одну
|
||||
операцию не задерживает, а `failed` от уже отработавшего guard **не** считается
|
||||
непокоем — иначе он заблокировал бы `repair`, которым и чинят последствия.
|
||||
|
||||
## D1g. Успешная установка не оставляет следов транзакции
|
||||
|
||||
Проверяется на чистом хосте, обычной успешной установкой. Это обратная проверка
|
||||
@@ -1204,6 +1267,11 @@ hy2xs-orchestrator doctor
|
||||
- `status`/`diagnostics` не блокируются и сообщают об идущей операции;
|
||||
- замок не переживает своего держателя.
|
||||
|
||||
4c. **Аварийная смерть с вооружённым guard** (сценарий D1h):
|
||||
- новая операция отказывает, пока `hy2xs-fw-rollback-*` ещё активен, в том
|
||||
числе когда замка не осталось вовсе;
|
||||
- после срабатывания guard `repair` проходит.
|
||||
|
||||
5. **Partial install + repair**:
|
||||
- состояние `install-state` фиксирует промежуточную фазу;
|
||||
- `repair` завершает граф до `installed=true`.
|
||||
@@ -1295,3 +1363,6 @@ hy2xs-orchestrator doctor
|
||||
65. откат восстанавливает `enabled`/`active` состояние `nftables.service`, а не только файлы правил
|
||||
66. операции жизненного цикла сериализованы эксклюзивным замком: вторая операция отказывает до первой мутации, а `status`/`diagnostics` не блокируются
|
||||
67. замок снимается при любом завершении держателя, включая `Ctrl+C`, SIGTERM и обрыв SSH; замок мёртвого держателя переиспользуется безопасно
|
||||
68. новая операция не начинается, пока у предыдущей остаётся вооружённый rollback guard: условие старта — «у предыдущей нет исполнителей, способных изменить систему», а не «её PID мёртв»
|
||||
69. отказ записи маркера `auto-rollback-fired` не может привести к фиксации успеха: он переводит юнит guard в `failed`, а `failed` фиксацию запрещает
|
||||
70. восстановление `UnitFileState` у `nftables.service` не обещает точности, которой не даёт: восстанавливаются `enabled`/`disabled`, остальные состояния называются оператору и не трогаются
|
||||
|
||||
@@ -197,6 +197,33 @@ operation lock … exists but is not a valid HY2XS lock record
|
||||
В отчёте `status` при этом появляется поле `operation_in_progress` — читайте
|
||||
состояние как снимок незавершённой транзакции, а не как итог.
|
||||
|
||||
### Операция отказывает: guard предыдущей операции ещё вооружён
|
||||
|
||||
```text
|
||||
previous HY2XS operation is no longer running, but its firewall rollback guard
|
||||
is still armed: hy2xs-fw-rollback-<op-id>.timer (active)
|
||||
```
|
||||
|
||||
Предыдущая операция умерла аварийно **после** применения firewall. Её процесса
|
||||
уже нет — замка может не быть тоже, — но rollback guard это отдельный объект
|
||||
systemd, и он переживает свой процесс. Если начать новую операцию сейчас, guard
|
||||
сработает посреди неё и вернёт firewall, существовавший до **предыдущей**
|
||||
операции.
|
||||
|
||||
Ничего делать не нужно, кроме как подождать: окно guard — 45 секунд с момента
|
||||
применения firewall.
|
||||
|
||||
```bash
|
||||
# сколько ещё ждать и что именно висит
|
||||
systemctl list-units --all 'hy2xs-fw-rollback-*'
|
||||
hy2xs-orchestrator status --package-dir /usr/local/lib/hy2xs/package
|
||||
```
|
||||
|
||||
Когда guard сработает, юнит перестанет быть `active`, и операция пройдёт.
|
||||
Состояние `failed` у него покою не мешает: оно означает, что откат отработал
|
||||
не полностью, и это как раз повод запустить `repair`, а не ждать дальше —
|
||||
подробности в `journalctl -u 'hy2xs-fw-rollback-*'`.
|
||||
|
||||
### Установка отказала с `firewall_guard_fired`
|
||||
|
||||
```text
|
||||
|
||||
@@ -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, поэтому перезагрузка снимает замок в любом случае.
|
||||
Удалять файл руками нужно только если в нём оказалось непонятное содержимое:
|
||||
такой замок сознательно не переиспользуется автоматически — непонятый файл не
|
||||
|
||||
Reference in New Issue
Block a user