Runner container never receives DOCKER_HOST — Quadlet sets it in [Service] instead of [Container] #5

New issue

Closed

opened 2026-08-24 03:58:10 +00:00 by agent-pi · 1 comment

agent-pi commented

2026-08-24 03:58:10 +00:00

Collaborator

On a fresh machine, zhuiri.service crash-loops at startup and systemd eventually gives up with start-limit-hit. The runner log shows:

Error: cannot ping the docker daemon. is it running? Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Investigation shows the runner container never sees the DOCKER_HOST variable at all. The Quadlet unit sets Environment=DOCKER_HOST under the [Service] section, which only applies to the podman run CLI process on the host — systemd does not forward it into the container, and the runner image has no DOCKER_HOST baked in.

With config.yml docker_host: "-", the runner (v12.12.0) looks up DOCKER_HOST in its own environment, finds nothing, and falls back to scanning well-known socket paths, where /var/run/docker.sock is checked first. So the daemon ping goes to the wrong socket (or a dead one), and startup fails.

On a fresh machine, zhuiri.service crash-loops at startup and systemd eventually gives up with start-limit-hit. The runner log shows: Error: cannot ping the docker daemon. is it running? Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? Investigation shows the runner container never sees the DOCKER_HOST variable at all. The Quadlet unit sets Environment=DOCKER_HOST under the [Service] section, which only applies to the podman run CLI process on the host — systemd does not forward it into the container, and the runner image has no DOCKER_HOST baked in. With config.yml docker_host: "-", the runner (v12.12.0) looks up DOCKER_HOST in its own environment, finds nothing, and falls back to scanning well-known socket paths, where /var/run/docker.sock is checked first. So the daemon ping goes to the wrong socket (or a dead one), and startup fails.

agent-pi commented

2026-08-24 03:58:57 +00:00

Author

Collaborator

Further findings (all verified on nixos, podman 5.8.6, forgejo-runner v12.12.0):

Quadlet dry-run confirms [Container] Environment=FOO=bar generates podman run --env FOO=bar, while [Service] Environment= only sets the env of the podman CLI process.
Empirically, podman run does not forward its parent environment into the container: env DOCKER_HOST=... podman run --rm <img> env shows no DOCKER_HOST inside.
Runner source (internal/app/cmd/daemon.go, getDockerSocketPath): with docker_host: "-" it does os.LookupEnv("DOCKER_HOST") first; if unset it scans commonSocketPaths in order, /var/run/docker.sock first.
The image env only sets PATH and HOME=/data (no XDG_RUNTIME_DIR), so even with the socket mounted at /run/user/1000/podman/podman.sock and no env var, the scan finds nothing and startup fails with "daemon Docker Engine socket not found and docker_host config was invalid".

Plan of attack:

quadlet/zhuiri.container: move Environment=DOCKER_HOST=unix:///run/user/%U/podman/podman.sock from [Service] into [Container] (keeping its comments). Quadlet then passes it via --env; systemd expands %U in the ExecStart line as it already does for the Volume= paths.
Verify with the Quadlet generator dry-run and an end-to-end manual podman run of the daemon.

Further findings (all verified on nixos, podman 5.8.6, forgejo-runner v12.12.0): - Quadlet dry-run confirms `[Container] Environment=FOO=bar` generates `podman run --env FOO=bar`, while `[Service] Environment=` only sets the env of the podman CLI process. - Empirically, `podman run` does not forward its parent environment into the container: `env DOCKER_HOST=... podman run --rm <img> env` shows no DOCKER_HOST inside. - Runner source (`internal/app/cmd/daemon.go`, `getDockerSocketPath`): with `docker_host: "-"` it does `os.LookupEnv("DOCKER_HOST")` first; if unset it scans `commonSocketPaths` in order, `/var/run/docker.sock` first. - The image env only sets `PATH` and `HOME=/data` (no `XDG_RUNTIME_DIR`), so even with the socket mounted at `/run/user/1000/podman/podman.sock` and no env var, the scan finds nothing and startup fails with "daemon Docker Engine socket not found and docker_host config was invalid". Plan of attack: - `quadlet/zhuiri.container`: move `Environment=DOCKER_HOST=unix:///run/user/%U/podman/podman.sock` from `[Service]` into `[Container]` (keeping its comments). Quadlet then passes it via `--env`; systemd expands `%U` in the ExecStart line as it already does for the Volume= paths. - Verify with the Quadlet generator dry-run and an end-to-end manual `podman run` of the daemon.

agent-pi referenced this issue from a pull request that will close it,

2026-08-24 04:00:51 +00:00

Pass DOCKER_HOST into the runner container; document NixOS podman socket setup #7

agent-pi closed this issue

2026-08-24 04:40:06 +00:00