Nik Afiq
a93818146a
Some checks failed
validate / lint (push) Failing after 1s
Both Deployments' rolling update briefly ran an old+new pod pair on the same node (node-role: storage), sharing the same config storage (qbittorrent's PVC, jdownloader's hostPath) -- both apps are effectively singletons that lock their config directory, so the new instance conflicted with the still-running old one: - qbittorrent: hit a known qbittorrent:5.2.0 image bug (linuxserver/ docker-qbittorrent#432) where a stale WebUI lockfile prevents the server from ever binding its port while a second instance is present -- surfaced as the new pod's readiness probe getting "connection refused" indefinitely. On top of that, my livenessProbe (30s/30s) was killing the container (exitCode 137) before qbittorrent had any chance to come up at all. Dropped the livenessProbe (readiness alone can never kill a container, only mark it not-ready) and loosened the readinessProbe timing. - jdownloader: the new pod's app process detected the old instance's lock in the shared /data/jdownloader hostPath and exited cleanly (exitCode 0) rather than run a duplicate copy -- nothing to do with probe timing. Both Deployments now use `strategy: Recreate` instead of the RollingUpdate default, so any future rollout fully stops the old pod before starting the new one -- this is the actual fix (matches the pattern immich.yaml already used). Applying this will briefly restart both currently-running pods to verify it. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>