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
Always enable cgroup namespace for containers #3735
base: master
Are you sure you want to change the base?
Conversation
In cgroupv2 hierrachy, cgroup setup for nested containers (i.e. docker) are incorrect without enabling cgroup namespace. This enables cgroup namespace for all containers to fix the incorrect cgroup setup. See linuxkit#3734 Signed-off-by: Daniel Dao <dqminh89@gmail.com>
Thanks for the PR! I've enabled the CI, although it might not test the change. I'll investigate. |
A progress update: when I enabled this locally I wasn't able to get |
@djs55 I think this might be related to something I'm looking at as well related to docker. Ignoring for the moment that the example on master doesn't build (something is wrong with the container image that gets stored, and so the resultant image doesn't appear to actually even have docker in it...), docker fails with the error below in my testing which I believe is related to cgroups:
|
@the-maldridge interesting! I'll take a look at the example on master when I get a moment. It would be good to fix it and make sure the end-to-end tests are properly testing it. I've seen a very similar error with
So I guess we should make sure the example works in both cgroup v1 and (default) cgroup v2 mode, if possible. |
Well this is far from transient, it happens without fail on every machine and instance I try this image on. I'm happy to pull logs or whatever else might be helpful to get this figured out because this is preventing docker from working and that is preventing me from updating things. |
I have done some more checking. I'm not really sure what's going on, but I figured I'd add more information. FWIW all this information is obtained from a system built with a patched linuxkit that includes this PR. The docker error is the same above, it cannot setup the container due to the controller being in the "wrong" spot. I really think this may be a case where docker wants to see the host cgroups paths since its talking at least as far as its concerned to a host containerd.
This really does look like something is wrong with the way that docker is interacting with the way the host cgroups work, and it seems to have changed between v0.8 and here (though so too has a lot of other stuff). |
Further research shows that the breaking component between v0.8 and here is runc. This is where I have to temporarily admit defeat as I don't understand enough of how runc and containerd slot together to fully understand what's going on here. All I know is that older versions of runc work and newer versions do not. I'll take a look at the runc changelog when I have time to see if I can find a specific issue. |
Further progress! Any version of runc past v1.0.0-rc90 breaks linuxkit. Not sure if its worth running a bisect through runc or not as runc appears to have introduced go modules at some point during that time which makes it tricky to build a nice one-line bisect. |
A complete bisect finds that opencontainers/runc 60e21ec is the first bad commit. I don't see what to do from here, but a lot of work after that point in the runc tree has to do with cgroupsv2, and edits to the way it handles cgroups in general. |
@the-maldridge I suspect the problem causing the
|
Fix #3734
In cgroupv2 hierrachy, cgroup setup for nested containers (i.e. docker)
are incorrect without enabling cgroup namespace. This enables cgroup
namespace for all containers to fix the incorrect cgroup setup.