fizzlepoof/truenas-stacks
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: clarify Serenity old-IP probe removal
Some checks failed
secret-guardrails / artifact-secret-scan (push) Has been cancelled
Details
secret-guardrails / gitleaks (push) Has been cancelled
Details

Browse Source
This commit is contained in:
Fizzlepoof
2026-05-25 20:37:10 +00:00
parent 54bf27b208
commit 733b661721
3 changed files with 24 additions and 20 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
docs/troubleshooting/KNOWN_QUIRKS.md
View File

@@ -71,15 +71,12 @@ Per-service gotchas that aren't bugs but will bite you if you forget them.
- Dead container, should be removed
### Serenity Newt / Pangolin stale health-check IP drift
- Several Serenity Newt-backed Pangolin targets were corrected to `ip=localhost` but still retained stale `hcHostname=10.5.1.5`, so Newt health checks kept failing with `no route to host`
- Several Serenity Newt-backed Pangolin targets were corrected to `ip=localhost`/`10.5.30.5` but still retained stale `hcHostname=10.5.1.5`, so Newt health checks failed with `no route to host`
- Verified affected target IDs on 2026-05-25: `15`, `20`, `25`, `29`, `56`, `57`, `58`, `69`
- Fast live recovery on Serenity: add runtime compatibility alias `10.5.1.5/32` on `br0`
- command used: `ip addr add 10.5.1.5/32 dev br0`
- Verified results after alias:
- Newt logged recovery to healthy for targets `15`, `20`, `25`, `29`, `56`, `57`
- direct HTTP probes to `http://10.5.1.5:8785/` and `http://10.5.1.5:8457/` returned `200`
- `docker exec Newt` confirmed `wget` success to ports `8785` and `8457`
- This is a runtime workaround, not an authoritative fix. It will disappear on reboot unless deliberately persisted, and the real cleanup is still to rewrite Pangolin health-check hostnames away from the stale pre-renumbering IP.
- A temporary local `/32` alias on Serenity (`ip addr add 10.5.1.5/32 dev br0`) proved the diagnosis by flipping multiple targets back to healthy
- That alias was then removed because the old `10.5.1.5` address is no longer allowed on the VLAN
- After removal, targets immediately fell back to unhealthy on the same stale health-check URLs, confirming the real problem is authoritative Pangolin metadata drift, not local app failure
- Treat the alias only as a diagnostic probe; do not persist it. The correct fix is to rewrite Pangolin health-check hostnames away from the stale pre-renumbering IP.
---