From d2d79b4f5f3755158a3f7d0c44e41bdb06435171 Mon Sep 17 00:00:00 2001 From: Claude Date: Mon, 27 Jul 2026 10:22:19 +0200 Subject: [PATCH] Restart the tunnel services after the hub they live inside MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both VPN services share the provisioning container's network namespace, and a process holds the namespace it started in. Restarting the hub — which every deploy does, to pick up new code — therefore leaves them listening inside a namespace that no longer exists. Nothing errors. The containers stay up, Caddy's log still reports it is serving on the tunnel address, and connections to that address are simply refused. It looks precisely like a gateway that never worked, which is how it presented on the live server after the first successful start. Co-Authored-By: Claude Opus 5 --- deploy/update.sh | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/deploy/update.sh b/deploy/update.sh index 6f9fcb4..51d8a2f 100755 --- a/deploy/update.sh +++ b/deploy/update.sh @@ -316,6 +316,15 @@ docker compose up -d # keep running the code from before the update. docker compose restart queue queue-provisioning scheduler reverb +# AFTER the hub, always. Both VPN services live in the provisioning container's +# network namespace, and a process holds the namespace it started in — so once +# the hub is restarted they are listening inside one that no longer exists. +# Nothing errors; connections to the tunnel address are simply refused, which +# looks exactly like the gateway never having worked. +if grep -qE '^COMPOSE_PROFILES=.*vpn' .env 2>/dev/null; then + docker compose --profile vpn restart vpn-dns vpn-gateway >/dev/null 2>&1 || true +fi + reconcile_vpn_readiness log "Leaving maintenance mode"