The installed unit started HAProxy with the static entry config alone:
-Ws -f /etc/haproxy/haproxy.cfg
That file declares the frontends, the reject backends and the timeouts; the
per-domain backends and the routing maps live in the generation the panel
publishes, and the maps' paths point at it. So HAProxy came up healthy, bound
80/443 and answered 404 on :80 and closed every :443 connection — no managed
domain was reachable. `haproxy -c` on the entry config alone passes, which is
why the install-time check did not catch it.
- the unit now passes both files, the generation through "current" so a reload
picks up whatever the panel published last;
- 30-haproxy.sh validates exactly that command line (entry + generation) and
requires domains.cfg AND both maps before it considers the bootstrap
generation in place, so the pre-start check can no longer pass a setup that
serves nothing;
- tests: TestUnitLoadsBothConfigFiles parses the unit's own ExecStart and fails
if it does not pass two config files, and TestUnitCommandLineRoutesTraffic
runs that command line against a real HAProxy and asserts a registered host
reaches its backend. Both fail against the old unit.
Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
