Weird failure with Docker --runtime io.containerd.runsc.v1 flag

[dperny]

Description

When attempting to execute a Docker container using gVisor by way of the --runtime flag as below, the container fails to start with this error:

$ sudo docker run --runtime io.containerd.runsc.v1 --rm -it hello-world
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: creating container: cannot set up cgroup for root: configuring cgroup: write /sys/fs/cgroup/system.slice/cgroup.subtree_control: no such file or directory

However, first executing a gVisor container through any one of a number of other methods first succeeds, and, here's the weird part, subsequent runs of the same command above also succeed. This persists until the system is rebooted.

The reproduction steps cover Ubuntu 24.04, but I have observed this same behavior on RHEL 10.

Please let me know if this looks like a Docker bug, and I'll carry this over there.

Steps to reproduce

1. Install Docker per instructions in the Dockers docs.
2. Install runsc using the script at the top of the gVisor docs.
3. Attempt to run the hello-world image with runsc runtime using this command: sudo docker run --rm -it --runtime io.containerd.runsc.v1 hello-world. It fails with this error message:

docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: creating container: cannot set up cgroup for root: configuring cgroup: write /sys/fs/cgroup/system.slice/cgroup.subtree_control: no such file or directory

4. Do any of the following, all of which succeed:
   1. Execute sudo runsc do echo hello world
   2. Execute a container through containerd directly: ctr image pull docker.io/library/hello-world && ctr run --runtime io.containerd.runsc.v1 --rm -t docker.io/library/hello-world:latest hello-world
   3. Execute sudo runsc install (which installs using the binary path), perform the appropriate steps to restart the Docker daemon. Run using --runtime runsc.
5. Reattempt running hello-world using the same command from step 3. The run now succeeds.
6. Upon restarting the machine (sudo shutdown -r now), the io.containerd.runsc.v1 runtime fails until one of the commands from step 4 is run. Restarting the Docker daemon sudo service docker restart does not cause anything to become broken again; only restarting the system does.

runsc version

$ sudo runsc --version
runsc version release-20260520.0
spec: 1.2.1

docker version (if using docker)

$ sudo docker version
Client: Docker Engine - Community
 Version:           29.5.2
 API version:       1.54
 Go version:        go1.26.3
 Git commit:        79eb04c
 Built:             Wed May 20 14:42:18 2026
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          29.5.2
  API version:      1.54 (minimum version 1.40)
  Go version:       go1.26.3
  Git commit:       568f755
  Built:            Wed May 20 14:42:18 2026
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v2.2.4
  GitCommit:        193637f7ee8ae5f5aa5248f49e7baa3e6164966e
 runc:
  Version:          1.3.5
  GitCommit:        v1.3.5-0-g488fc13e
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

#### containerd version

$ sudo ctr version
Client:
  Version:  v2.2.4
  Revision: 193637f7ee8ae5f5aa5248f49e7baa3e6164966e
  Go version: go1.25.10

Server:
  Version:  v2.2.4
  Revision: 193637f7ee8ae5f5aa5248f49e7baa3e6164966e
  UUID: 06cced5e-a87b-4e92-b6ea-9ffe12ddd0e2

uname

Linux ip-172-31-0-211 6.17.0-1012-aws #12~24.04.1-Ubuntu SMP Mon Apr 6 17:36:28 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

kubectl (if using Kubernetes)

repo state (if built from source)

No response

runsc debug logs (if available)

[EtiennePerot]

It's possible that the cgroup configuration code isn't idempotent, and that this error message would come from somewhere in the middle of it. What does the cgroupfs hierarchy look like (and what does /sys/fs/cgroup/system.slice/cgroup.subtree_control look like) before the first command vs after the first command vs after the second?

[milantracy]

it is unlikely to be gvisor/runsc issue

The gVisor shim assumes the controllers are already initialized and crashes when the kernel rejects its write attempt by systemd.

when you run docker install, the gvisor's runsc will registered to your docker's /etc/docker/daemon.json, it changes how Docker initializes systemd on startup, preventing the bug, same for ctr, ctr forces containerd to initialize the path and controllers.

can you try the dynamic runtime flag with other runtime? I expect to see the issue because of systemd lazy initialization.

[dperny]

Trying it with other runtimes is a very good idea and I'm not sure why I didn't think of it. I'm going to do that and see what shakes out. If I can repro with another runtime, I'll close this issue and go bother the Docker folks instead.

[corhere]

when you run docker install, the gvisor's runsc will registered to your docker's /etc/docker/daemon.json, it changes how Docker initializes systemd on startup, preventing the bug, same for ctr, ctr forces containerd to initialize the path and controllers.

gVisor's docker install edits the docker daemon configuration to add a named runtime with Path and RuntimeArgs. (It also optionally adds a native.cgroupdriver= exec-opt. Docker defaults to the systemd cgroup driver when it detects that a unified cgroup v2 hierarchy is mounted.) When Docker starts a container with a runtime configured with a Path it instructs containerd to invoke the io.containerd.runc.v2 shim with options telling the shim to launch the runtime at Path instead of the default runc. The SystemdCgroup: true option instructs the shim to initialize the cgroup controllers before launching the runtime binary.

When running a Docker container with --runtime io.containerd.runsc.v1 the Docker Engine passes that value as the runtimeType into containerd with no options. The end result is that containerd invokes the containerd-shim-runsc-v1 binary it finds on its $PATH with no options. What's really strange is that ctr run --runtime does the same thing.

To summarize:

• runsc invoked from containerd-shim-runc-v2 with the SystemdCgroup: true option succeeds.
• runsc invoked from containerd-shim-runsc-v1 with no options via dockerd fails to start due to uninitialized cgroup controllers.
• runsc invoked from containerd-shim-runsc-v1 with no options via ctr run succeeds?!

The runtime options passed to containerd would be the same with both docker run --runtime io.containerd.runsc.v1 and ctr run --runtime io.containerd.runsc.v1. Could it be some difference in the OCI spec generated by ctr compared to dockerd that is resulting in a difference in how runsc behaves?