From 192bb30a4b96874eb9b58ddb8d355a6ac7277d54 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Mon, 22 Jun 2026 21:16:45 +0200 Subject: [PATCH] test campaign #3: Phase 1 resource starvation (R1-R4 fail-safe held) Co-Authored-By: Claude Opus 4.8 (1M context) --- TEST-REPORT.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/TEST-REPORT.md b/TEST-REPORT.md index de19b22..35562d7 100644 --- a/TEST-REPORT.md +++ b/TEST-REPORT.md @@ -9,7 +9,14 @@ handles-or-fails-safe, then recovers. Every break carries a timed auto-revert; P - ctrl **v0.75.0** healthy; agent v0.39.0; **25 containers, 0 unhealthy**; rootfs `/` 4%, `/var/lib/docker` 8%, drives 1%; mem **8.8 Gi available**. - Floor: PBS `felhom-pbs:backup/ct/9201/2026-06-22T19:01:56Z` (success, crash-consistent, verified). -## Phase 1 — Resource starvation — _pending_ +## Phase 1 — Resource starvation — **PASS (fail-safe held)** + +| # | Break (timed-revert) | Result | Evidence | +|---|---|---|---| +| R1 | python hog ~8 GB (~91% RAM), 75s | **PASS** | mid-stress: 10Gi used / 1.1Gi avail — controller **healthy**, 25/0 unhealthy; post: **dockerd NRestarts=0, no OOM** (alloc fit via cache eviction), recovered to 8.9Gi. Backstop pkill guard armed. | +| R2 | settings save on full disk | **PASS (code-verified)** | `settings.save()` = atomic write-`.tmp`-then-`os.Rename` (`settings.go:236-261`) → a disk-full fails at WriteFile, original untouched. Live disk-full not reproducible: settings.json is on the 252 GB docker vol. | +| R3 | fill rootfs (holds `/mnt/sys_drive` backups) to 94% (timed rm @150s) | **PASS** | controller stayed healthy (it's on the separate 252 GB vol); DB-dump + Tier-2 (8 apps, immich 155MB) **succeeded**; **settings.json stayed valid JSON** (no corruption). Reverted → rootfs 4%. (Literal-full refusal not pushed — near-0 rootfs risks wedging the guest OS unattended; the 2 GB margin had room so the gate didn't need to refuse.) | +| R4 | memory gate hard-block | **PASS (code-verified)** | `deploy.go:186` is a **hard block** (returns an error on `committed+new > usable`), using **committed-memory** accounting (sum of deployed `mem_request`), reserved 384 MB, usable 11904 MB. Live committed ≈ 4.4 GB → ~7.5 GB headroom, so tripping needs mass-deploying ~7.5 GB of requests (impractical/risky unattended); the branch + math are verified. | ## Phase 2 — State corruption [HIGH SEV] — _pending_ ## Phase 3 — Concurrency storms — _pending_ ## Phase 4 — Time chaos — _pending_