vps: haproxy unit waits for a default route #303

Merged

mysticalsoap merged 1 commit from fix/haproxy-boot-order into trunk

2026-09-21 00:24:06 -04:00

mysticalsoap commented

2026-09-21 00:15:37 -04:00

Owner

Problem

After the first reboot of the rebuilt VPS, WireGuard came up and haproxy.service reported active with pasta holding 80/443/27341, but every public request got a TCP reset and nothing arrived at the home end (tunnel receive counter flat during a request; home HAProxy log empty). The VPS host itself could connect to 10.77.0.2:8443. pasta derives the container's addresses and routes from the host's default-route interface once, at start, and the lingering relay user's manager ran it before the host had that route, so the container came up with link-local addressing: published ports accepted connections, backend connects over the tunnel failed. A healthy-looking full outage.

Fix

ExecStartPre loop in the Quadlet unit that waits for an IPv4 default route before pasta starts. A user unit cannot order after the system's network-online.target, so a wait is the only ordering available. The unit sits in activating during the wait rather than failing, so the start-limit lines from #301 are dropped.

Verification

sudo systemctl --user -M relay@ restart haproxy on the broken box restored service without any other change, confirming the start-time state was the fault.
just vps-deploy, then a VPS reboot at 04:13:33 UTC: public HTTPS answered 200 through the VPS at 04:15:24 with no intervention; port 80 redirects; all three ports bound.

## Problem After the first reboot of the rebuilt VPS, WireGuard came up and `haproxy.service` reported active with pasta holding 80/443/27341, but every public request got a TCP reset and nothing arrived at the home end (tunnel receive counter flat during a request; home HAProxy log empty). The VPS host itself could connect to `10.77.0.2:8443`. pasta derives the container's addresses and routes from the host's default-route interface once, at start, and the lingering relay user's manager ran it before the host had that route, so the container came up with link-local addressing: published ports accepted connections, backend connects over the tunnel failed. A healthy-looking full outage. ## Fix `ExecStartPre` loop in the Quadlet unit that waits for an IPv4 default route before pasta starts. A user unit cannot order after the system's `network-online.target`, so a wait is the only ordering available. The unit sits in activating during the wait rather than failing, so the start-limit lines from #301 are dropped. ## Verification - `sudo systemctl --user -M relay@ restart haproxy` on the broken box restored service without any other change, confirming the start-time state was the fault. - `just vps-deploy`, then a VPS reboot at 04:13:33 UTC: public HTTPS answered 200 through the VPS at 04:15:24 with no intervention; port 80 redirects; all three ports bound.

mysticalsoap added the

bug

vps

labels

2026-09-21 00:15:37 -04:00

mysticalsoap added 1 commit

2026-09-21 00:15:38 -04:00

vps: haproxy unit waits for a default route

validate / validate (pull_request) Successful in 25s

Details

5ace8d36fd

pasta reads the host's addresses and routes from the default-route
interface once, at start. At boot the lingering relay user's manager
started it before the host had that route, so the container came up
with link-local addressing: the published ports accepted connections
and every backend connect over the tunnel failed, a full outage that
looked healthy from the unit's point of view. A user unit cannot order
after the system's network-online.target, so the wait is an
ExecStartPre loop; the unit sits in activating rather than failing, so
the start-limit lines are not needed.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

mysticalsoap merged commit 7d9b280ff6 into trunk

2026-09-21 00:24:06 -04:00

mysticalsoap deleted branch fix/haproxy-boot-order

2026-09-21 00:24:06 -04:00

mysticalsoap referenced this pull request from a commit

2026-09-21 00:24:08 -04:00

Merge pull request 'vps: haproxy unit waits for a default route' (#303) from fix/haproxy-boot-order into trunk