You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On the enviroment of a cgroupv2 host, running a container within a container failed.
// cgroup version on the host
[root@vm-66 ~]# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
// launch a container named A on the host
[root@vm-66 ~]# docker run --privileged -v /root/qiaochen/docker/docker:/root/docker -v /root/qiaochen/busybox.tar:/root/busybox.tar -it --name A --rm b29364c93f57 sh
// start daemon in container A
dockerd --iptables=false --debug
// launch container B in container A
sh-4.2# docker run -it -m 20M --name qc2 --rm busybox sh
docker: Error response from daemon: failed to create task forcontainer: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: unable to apply cgroup configuration: cannot enter cgroupv2 "/sys/fs/cgroup/docker" with domain controllers -- it isin threaded mode: unknown.
// when c.path is like /foo/bar/baz, the following files need to be written:// * /sys/fs/cgroup/cgroup.subtree_control// * /sys/fs/cgroup/foo/cgroup.subtree_control// * /sys/fs/cgroup/foo/bar/cgroup.subtree_control// Note that /sys/fs/cgroup/foo/bar/baz/cgroup.subtree_control does not need to be written.
The container started on the host does not have the parent controllers inherited in the final cgroup.subtree_control. As a result, when a container is launched within the parent container, the child container's cgroup does not have any controllers.
What version of containerd are you using?
1.7.6
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response
The text was updated successfully, but these errors were encountered:
@AkihiroSuda Yes, I can manually add controllers, but I wonder if containerd should automatically add the parent cgroup's controllers when starting a container? It seems more logical this way. Alos, should containerd also provide an interface to define the container's sub-controllers on the cgroup2 system?
I think the default behavior for starting a container is to add all parent cgroup controllers. Providing a flag to customize the cgroup seems like a better option.
Description
On the enviroment of a cgroupv2 host, running a container within a container failed.
Steps to reproduce the issue
Describe the results you received and expected
I believe this is causing the failure to start a container within a container:
https://github.com/containerd/cgroups/blob/main/cgroup2/manager.go#L312
The container started on the host does not have the parent controllers inherited in the final cgroup.subtree_control. As a result, when a container is launched within the parent container, the child container's cgroup does not have any controllers.
What version of containerd are you using?
1.7.6
Any other relevant information
No response
Show configuration if it is related to CRI plugin.
No response
The text was updated successfully, but these errors were encountered: