jenkins role: unit inactive, web UI unreachable after 600s

[yakari007]

Summary

Deployed a VM with the jenkins service role attached (default http_port
8080, nothing overridden), on the Ubuntu 24.x "with PlusClouds Service"
image. After SSH login succeeded, systemctl is-active jenkins reported
inactive, and the web UI on :8080 never became reachable, even after
waiting an extended 600s budget (roughly double the default, to account
for Jenkins' Java prerequisite + package install + JVM startup).

Caveat: unlike a companion set of failures filed separately (#5, #6,
#7, #8, #9, where the systemd unit clearly existed and was failed/
inactive), I have not independently confirmed the actual Jenkins systemd
unit name on this image - jenkins is the standard name from Jenkins' own
Debian/apt packaging, but if this role installs it under a different unit
name, systemctl is-active jenkins would report the same "not active"-ish
result for the wrong reason. The web-UI check failing too (a
name-independent signal) is what makes this worth filing regardless, but
worth confirming service naming during triage.

Repro

POST /leo/iaas/virtual-machines/create-wizard with
service_roles: {"jenkins": {"config": {}}} against the Ubuntu 24.x "with
PlusClouds Service" image, then after boot (waited up to 600s):

systemctl is-active jenkins       # -> inactive
curl http://127.0.0.1:8080/       # -> unreachable

The VM was deployed and torn down automatically as part of the test run,
so the live VM/install-script 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]

Partially addressed in v1.6.3 (fa0b3be) — found and fixed one concrete, verified bug, though I can't be certain it's the entire explanation for the reported inactive state.

Root cause found: the role edited HTTP_PORT in /etc/default/jenkins, but I downloaded and inspected the actual current Jenkins Debian package (jenkins_2.568.1_all.deb) and confirmed its systemd unit (/usr/lib/systemd/system/jenkins.service) has no EnvironmentFile= directive at all — /etc/default/jenkins is only consulted by the legacy /etc/init.d/jenkins script. The actually-running systemd service gets its port from an inline Environment="JENKINS_PORT=8080" line baked into the unit itself, which the role never touched. So the port override was silently a no-op under systemd. Fixed by writing a proper systemd drop-in (jenkins.service.d/toolkit-http-port.conf) instead.

This confirms your caveat about not being 100% sure of the unit name was on the right track re: something being off between the role's assumptions and the packaged systemd unit — though the specific issue was the port config path, not the unit name itself (which is correctly jenkins.service/jenkins). Since the repro used the default port (8080, same as the package default), this particular bug wouldn't by itself explain total non-start — if it's still reproducible after this fix, the JVM cold-start time (package install + WAR unpack + plugin load) exceeding DefaultTimeoutStartSec (unit's Type=notify requires an sd_notify READY within that window, no TimeoutStartSec= override is currently set) is my next suspect, but I couldn't verify that without a real disposable VM to time a cold start on. Flagging for follow-up if it recurs.