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

[yakari007]

Summary

Deployed a VM with the loki service role attached (default/empty config

• no version/retention_period override submitted), on the Ubuntu 24.x
  "with PlusClouds Service" image. After SSH login succeeded, systemctl is-active loki reported failed for the full 300s verification window,
  and the /ready endpoint on :3100 was unreachable (curl couldn't connect
  at all - exit 7).

Repro

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

systemctl is-active loki   # -> failed
curl http://127.0.0.1:3100/ready   # -> connection refused/unreachable

The VM was deployed and torn down automatically as part of the test run,
so the live VM/journalctl -u loki output is gone - filed from the test's
captured output, not a live inspection.

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.

Downloaded the actual v3.6.13 release asset (loki-linux-amd64.zip), confirmed it contains exactly the single binary the role assumes, and ran it with the exact loki-config.yaml the role renders (including retention_period: 0s). It started cleanly — "Loki started", bound :3100/:9096, no errors. Couldn't reproduce the failed state from the role's own config/binary. If this recurs, journalctl -u loki from a live (non-torn-down) VM would be the fastest way to pin down what's actually different in the deployed environment.