gvisor #b8fa96e201bf79d9012ab60fddc560ff4a39165c not working w/ systemd-cgroups + cgroupsv2 + containerd
gpl opened this issue · comments
Description
We're trying to get gvisor working with cgroupsv2 and systemd-cgroup as we saw this cl: bf86207
However, we're unable to get a functioning result.
Steps to reproduce
On a Ubuntu 21.10 system, running kernel Linux 5.13.0-37-generic:
git clone https://github.com/google/gvisor; cd gvisor;
echo "module runsc" > go.mod
GO111MODULE=on go get gvisor.dev/gvisor/runsc@go
CGO_ENABLED=0 GO111MODULE=on sudo -E go build -o /usr/local/bin/runsc gvisor.dev/gvisor/runsc
GO111MODULE=on sudo -E go build -o /usr/local/bin/containerd-shim-runsc-v1 gvisor.dev/gvisor/shim
Then following the quick start steps here:
https://gvisor.dev/docs/user_guide/containerd/quick_start/
Invoking sudo crictl runp --runtime runsc sandbox.json results in:
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create containerd task: OCI runtime create failed: creating container: finding current cgroups: Rel: can't make . relative to /: unknown
runsc version
Commit b8fa96e201bf79d9012ab60fddc560ff4a39165cdocker version (if using docker)
No response
uname
Linux 5.13.0-37-generic #42-Ubuntu SMP Tue Mar 15 14:34:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
kubectl (if using Kubernetes)
1.23.3repo state (if built from source)
release-20220321.0-15-gb8fa96e20
runsc debug logs (if available)
No response
We believe it could be related to having two paths:
34 24 0:29 / /sys/fs/cgroup rw,nosuid,nodev,noexec,relatime shared:9 - cgroup2 cgroup2 rw
1479 28 0:29 / /run/cilium/cgroupv2 rw,relatime shared:650 - cgroup2 none rw
Thanks for reporting this issue. The gVisor systemd-group implementation assumes that the cgroupv2 root is mounted at /sys/fs/cgroup, so that could be the issue here. What is your use case for the two separate paths, and are you able to get this setup to run using a different runtime like runc?
Yep, this current configuration works fine with runc+containerd; the second path is introduced by an extension to Kubernetes (cilium.io) that we use.
The fix works perfectly for us; thank you!