Sign in

Search issue titles and bodies, change requests and comments. Private repositories you cannot read are not included.
vole
Clone

Read only, no credentials:

https://rodent.software/vole.git

Write over SSH with a registered key:

git clone ssh://git@rodent.software:2222/vole.git

A free and open-source forge that lives in your Git repo.

#241

P2: runner jobs fail under the system service because podman has no systemd user manager for cgroups

closed · opened by keenan 22h ago

keenan opened this 22h ago

After the base image pulls, the first RUN step fails:

STEP 6/7: RUN ["/bin/sh", "-c", "apt-get update && apt-get install -y ..."]
error running container: from /usr/bin/crun creating container for [/bin/sh -c apt-get update ...]:
  sd-bus call: Interactive authentication required.: Permission denied
Error: building at STEP "RUN ...": while running runtime: exit status 1

Podman had already warned about it:

level=warning msg="The cgroupv2 manager is set to systemd but there is no systemd user session available"
level=warning msg="Falling back to --cgroup-manager=cgroupfs"

The unit runs as a system service with User=ci-runner, so there is no user@1000.service for podman or crun to ask for a scope. Delegate=yes gives the service its own cgroup subtree, but nothing tells the runtime to use it, so crun falls back to sd-bus and fails.

What fixed it here

As ci-runner, /var/lib/vole-runner/.config/containers/containers.conf:

[engine]
cgroup_manager = "cgroupfs"

Scope

  • Decide where this belongs: a containers.conf the package or template writes, a drop-in environment setting, or a documented step. Right now neither docs/deploy/runner.md nor deploy/cloud-init/runner.yaml mentions cgroups at all.
  • Consider the alternative arrangement: run the runner as a user unit with loginctl enable-linger, which gives podman the user manager it wants and leaves the cgroup manager alone. That changes the unit’s shape, so it is a design choice rather than a docs fix.
  • Note the interaction with RuntimeDirectory and XDG_RUNTIME_DIR=/run/vole-runner: a lingering user session would live at /run/user/1000, so the two cannot both be assumed.

Acceptance criteria

A clean machine following only the documented steps runs a job whose workflow starts a container, with no manual cgroup configuration and no sd-bus warning that changes the outcome.

Related: #237 and #239 come before this one; the three together are the difference between the documented runner setup working and a machine that fails at the first job.

Comments (1)

keenan 4h ago

Taking this with #237 and #239 as one change.

Deciding for the drop-in and keeping the system unit:

  • The package ships /etc/containers/containers.conf.d/50-vole-runner.conf with [engine] cgroup_manager = "cgroupfs".
  • A drop-in merges with the distribution’s file instead of replacing it, which is why this is not CONTAINERS_CONF: an operator’s own containers.conf keeps applying, and so do the distribution’s defaults.
  • System configuration is read for rootless podman too, so it reaches ci-runner without a file in its home directory, which the package cannot own.
  • Delegate=yes stays and is now what the setting relies on: the service’s cgroup subtree is the one cgroupfs writes into.
  • The user unit with loginctl enable-linger alternative goes in the docs as the arrangement an operator may choose instead, with the conflict between a lingering session’s /run/user/1000 and the unit’s XDG_RUNTIME_DIR=/run/vole-runner written down, since the two cannot both be assumed.
  • Docs name what the sd-bus warning looks like and that it changes the outcome, so the first RUN failing is recognizable.