`gpu-proxy` (a FastAPI gateway on tselitedesk that wakes/sleeps a gaming PC on demand so its GPU can run Ollama for Hermes) stops Ollama and re-enables Windows sleep after a `SESSION_IDLE_TIMEOUT` of inactivity. A plain "is it idle?" question — "it should sleep sooner?" — led to checking whether that was actually happening. It wasn't: Windows had been sitting fully awake for far longer than the idle timeout, every time, with no error anywhere.
`poproom-fe` had been deploying the same stale image for several builds in a row — new commits went in, CI ran, but the running frontend never actually changed.
A live, in-use ConfigMap got silently overwritten by ArgoCD's selfHeal — not from a bad edit to the real config, but from a template file that was never meant to be applied at all.
The `LonghornInstanceManagerMemoryLeak` alert — added after [July's real instance-manager memory leak](/postmortems/2026-07-31-longhorn-instance-manager-leak) — fired again. Given the history, this looked like a recurrence of the same leak until the underlying pod turned out to have restarted recently, with memory usage nowhere near leak territory.
Revisiting [the July 31st instance-manager memory leak](/postmortems/2026-07-31-longhorn-instance-manager-leak) turned up that its "structural fix" — a daily recurring job meant to keep the MySQL volume's snapshot chain capped at 7 — has never actually deleted a single snapshot. It ran successfully every night for 25 straight days, creating one snapshot each time and pruning zero, growing the chain from 0 to 25 and quietly reproducing the exact growth mechanism that froze Jellyfin in July, just ~60x slower (2.7 MiB/day now vs. ~170 MiB/day then).
Jellyfin playback kept freezing on the living room LG TV — the kind of intermittent, hard-to-pin-down issue that immediately points at the server: storage, CPU, the network path, Longhorn (given [the July memory-leak incident](/postmortems/2026-07-31-longhorn-instance-manager-leak) on the same stack). Every server-side signal was checked live and came back clean.
A routine homelab shutdown (elitedesk → TrueNAS → OPNsense) turned into a multi-hour recovery after several independent issues compounded: `docker compose down` removed all 19 containers on elitedesk instead of just stopping them; elitedesk was moved from its onboard gig NIC to a new USB 2.5GbE adapter mid-session, changing its LAN IP from `.60` to `.99`; TrueNAS and OPNsense both power-cycled unexpectedly on their own; and the ISP router's port-forward rules (pointing at elitedesk's old `.60` IP) went stale, taking `jellyfin.sacenpapier.org`, `seerr.sacenpapier.org`, `ssh.sacenpapier.org`, and `mc.sacenpapier.org` down externally even after all services were healthy internally.
Set out to move Bob (the homelab's Hermes Agent instance) from Ollama/gpt-oss-20b to vLLM running Gemma 4 12B on an RTX 5080, chasing better tool-calling reliability. Got vLLM fully working after root-causing six separate platform bugs — then hit a service-killing SIGTERM every 20-40 seconds under real load that never got explained, despite ruling out every plausible cause. Abandoned vLLM/WSL2 entirely and shipped the same model (Gemma 4 12B) through Ollama running natively on Windows instead — which turned out to be the better architecture anyway, and along the way surfaced two pre-existing regressions in the gaming-safety system that had been silently broken for the entire session.
Auditing what was actually under ArgoCD turned up an unreachable but still-running MySQL instance (`mysql-longhorn`) holding real data. Its creation date and PVC name matched the Longhorn-backed instance from [the June 2nd incident](/postmortems/2026-06-02-mysql-k3s-recovery) — migrated off in that fix, but never actually decommissioned.
Rolling out ArgoCD across six apps, two repos (`Apercu`, `x`) turned out to declare an identically-named shared MySQL resource. Pointing separate ArgoCD Applications at that collision caused the shared database volume to be recreated from scratch, silently wiping live data for three apps — one of them (BotWhy) kept running normally the whole time, never throwing an error.