Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In a cgroup2 enviroment, runing a container in a container failed. #10083

Open
aa624545345 opened this issue Apr 17, 2024 · 2 comments
Open

In a cgroup2 enviroment, runing a container in a container failed. #10083

aa624545345 opened this issue Apr 17, 2024 · 2 comments

Comments

@aa624545345
Copy link

Description

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 for container: 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 is in threaded mode: unknown.

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

	// 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

@AkihiroSuda
Copy link
Member

You have to set up controllers like this
https://github.com/moby/moby/blob/v26.0.1/hack/dind#L59

@aa624545345
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants