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

Manually merged

marvin8 merged 2 commits from fix/issue-5-runner-docker-host into main

2026-08-24 04:38:07 +00:00

agent-pi commented

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

Collaborator

Fixes the startup crash-loop on fresh machines and makes the NixOS prerequisite actually work.

What happened: zhuiri.service crash-looped with cannot ping the docker daemon ... unix:///var/run/docker.sock and hit the systemd start limit. Two independent problems:

Environment=DOCKER_HOST was set under [Service], so it only reached the podman run CLI process — never the runner container. With docker_host: "-" the runner (v12.12.0 getDockerSocketPath) then scanned well-known socket paths, where /var/run/docker.sock is checked first, and pinged a socket that isn't a live podman endpoint. Moving the line into [Container] makes Quadlet emit --env DOCKER_HOST=... (verified with podman-system-generator --user --dryrun), and systemd expands %U in the ExecStart line as it already does for the Volume paths. Verified end-to-end: the daemon starts, declares itself to forge.marvin8.zone, and picks up jobs.
On NixOS the documented systemctl --user enable --now podman.socket prerequisite fails because the podman user unit is not in the user-manager search path. The store-symlink workaround dangles after podman upgrades + GC, leaving a zombie socket unit that holds no listening FDs — connection refused with no obvious cause. The README now documents installing the unit as a real file (content identical to the unit shipped with podman, ListenStream=%t/podman/podman.sock — no store-path dependency).

Closes #5
Closes #6

Fixes the startup crash-loop on fresh machines and makes the NixOS prerequisite actually work. **What happened:** zhuiri.service crash-looped with `cannot ping the docker daemon ... unix:///var/run/docker.sock` and hit the systemd start limit. Two independent problems: 1. `Environment=DOCKER_HOST` was set under `[Service]`, so it only reached the `podman run` CLI process — never the runner container. With `docker_host: "-"` the runner (v12.12.0 `getDockerSocketPath`) then scanned well-known socket paths, where `/var/run/docker.sock` is checked first, and pinged a socket that isn't a live podman endpoint. Moving the line into `[Container]` makes Quadlet emit `--env DOCKER_HOST=...` (verified with `podman-system-generator --user --dryrun`), and systemd expands `%U` in the ExecStart line as it already does for the Volume paths. Verified end-to-end: the daemon starts, declares itself to forge.marvin8.zone, and picks up jobs. 2. On NixOS the documented `systemctl --user enable --now podman.socket` prerequisite fails because the podman user unit is not in the user-manager search path. The store-symlink workaround dangles after podman upgrades + GC, leaving a zombie socket unit that holds no listening FDs — connection refused with no obvious cause. The README now documents installing the unit as a real file (content identical to the unit shipped with podman, `ListenStream=%t/podman/podman.sock` — no store-path dependency). Closes #5 Closes #6

agent-pi added 2 commits

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

🐛 pass DOCKER_HOST into the runner container 9940071c67

Move Environment=DOCKER_HOST from [Service] to [Container] so Quadlet
emits --env and the forgejo-runner actually sees it. Under [Service]
the variable only reached the podman CLI process; with docker_host:
"-" the runner then scanned common socket paths, found
/var/run/docker.sock first, and failed to ping the daemon.

Closes the crash-loop symptom tracked in the linked issue.

📝 document a stable podman.socket user unit for NixOS f417acc84b