alertmanager role: systemd unit ends up 'failed' after install

[yakari007]

Summary

Deployed a VM with the alertmanager service role attached (default/empty
config - no webhook_url submitted), on the Ubuntu 24.x "with PlusClouds
Service" image. After SSH login succeeded, systemctl is-active alertmanager reported failed (never reached active) for the full
300s verification window, and the /-/healthy endpoint on :9093 was
unreachable (curl couldn't connect at all - exit 7).

Repro

POST /leo/iaas/virtual-machines/create-wizard with
service_roles: {"alertmanager": {"config": {}}} against the Ubuntu 24.x
"with PlusClouds Service" image, then after boot:

systemctl is-active alertmanager   # -> failed
curl http://127.0.0.1:9093/-/healthy   # -> connection refused/unreachable

The VM was deployed and torn down automatically as part of the test run,
so the live VM/journalctl -u alertmanager output is gone - filed from the
test's captured output, not a live inspection. Happy to redeploy with
CLEANUP_AFTER_TEST=false and pull the actual unit logs if useful.

Found via leo4.tester's iaas-service-roles automated test scenario.

[yakari007]

Investigated but did not find a reproducible code-level bug, so no change made yet.

I downloaded the actual v0.33.1 release asset (alertmanager-0.33.1.linux-amd64.tar.gz — matches exactly what the role's URL template builds), rendered alertmanager.yml through the real Jinja engine with the exact defaults from this repro (empty webhook_url), confirmed it's valid parseable YAML, and ran the actual binary with that exact config + the exact --config.file/--storage.path flags from the systemd unit. It started cleanly with no errors (bound :9093, no crash) — so I couldn't reproduce the failed state from the role's own config/binary. I don't have a disposable VM to test the systemd-specific bits (running as the unprivileged alertmanager user, capability handling isn't relevant here since :9093 is unprivileged), so if this is still reproducible, capturing journalctl -u alertmanager from a live (non-torn-down) VM would help a lot — that's the one thing I can't get from static analysis.