admin/felhom-controller
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test campaign #2: Phase 4 (concurrent-restore mutex + stopped-stack backup PASS; snapshots-404 + additive-restore gaps re-confirmed)

Browse Source 
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
authentik Default Admin
2026-06-22 19:07:51 +02:00
parent 61b2dc02a4
commit 608cd02dd4
1 changed files with 11 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TEST-REPORT.md
+11 -1
View File
@@ -59,7 +59,17 @@ Agent path works (v0.74.0), so these ran through the real controller→agent pip
| C8 | guest reboot during a backup op | **PASS** | triggered DB-dump + `pct reboot 9201` mid-op → recovered to 26 containers/0 unhealthy; **drives remounted by UUID** (felhom-flash /dev/sdc1, felhom-usb /dev/sdb1, ext4); cloudflared+controller healthy; **romm DB intact (17 tables — no corruption)**; UI 200 |
**🔴 Finding (C1/C2) — docker restart policy not honored:** containers with `restart: unless-stopped` do **not** auto-restart after `docker kill` (navidrome `RestartCount=0` over two trials; dockerd logged `stopping restart-manager`; Docker 29.5.3, Live Restore off). The controller is not stopping them (no reconcile-stop in logs/source). Impact: **no docker-level self-heal for crashed app or controller containers** — the controller detects the stopped state and a UI/operator restart recovers apps, but a crashed *controller* itself has no automatic recovery (oneshot bootstrap + dead restart policy). **Needs supervised investigation** (docker daemon restart-manager behaviour) + a controller-recovery watchdog (e.g. bootstrap as a `Restart=always` monitor, or a systemd unit watching the container).
## Phase 4 — Backup/restore edge cases — _pending_
## Phase 4 — Backup/restore edge cases — **PASS (gaps re-confirmed)**
| Check | Result | Evidence |
|---|---|---|
| Concurrent restore → running-mutex blocks the 2nd | **PASS** | restore #1 (romm) running → restore #2 → 302 flash_error "Visszaállítás sikertelen: **backup or restore already in progress**"; #1 completed; romm healthy. No double-run/corruption |
| Backup with a stack already stopped | **PASS** | stopped uptime-kuma → `/api/backup/run` → ok:true, completed, **no backup errors in logs**; uptime-kuma restarted → healthy. (Tier-2 then returned single-flight "Mentés már folyamatban" — the DB-dump was still running) |
| Gap re-confirm: `/api/backup/snapshots` | **STILL 404** | `{"ok":false,"error":"endpoint not found"}` — restore-UI snapshot dropdown still can't populate (restore works via `POST /backup/restore`) |
| Gap re-confirm: restore DB import is additive | **CONFIRMED** | planted `c2_restore_marker` (romm 17→18 tbl) → restore → marker **survived** (count=1, tables still 18); dropped afterward (back to 17) |
| Low-space backup behavior | SKIPPED | tied to C4 (filling 100+ GB impractical/unsafe unattended) |
Bonus across the phase: **single-flight** is robust — observed rejecting concurrent restore (mutex), concurrent whole-guest backup (C7), and Tier-2 vs DB-dump.
## Phase 5 — Host reboot (optional) — _pending_
---