[1.1] libctr/cgroups: don't take init's cgroup into account #3811
Conversation
|
PTAL @kolyshkin @mrunalp |
|
To reviewers: this is a backport of PR #3784 to release-1.1 branch. In comments to that PR, I tried to find out whether this change can break anything. TL;DR, my conclusion was (and still is) that this is not a breaking change. More to say, using PID 1's cgroup as a base is not correct when host pid ns is used, and thus it was removed a long time ago (but not for systemd cgroup driver). Now, this PR is required for the case where systemd is placed into a non-root cgroup. Such placement is needed in recent kernels, when we want some containers (cgroups) to have CPU load-balancing disabled ( |
|
DCO check is failing |
haircommander
force-pushed
the
root-cgroup-no-init-1.1
branch
from
43d85b3 to
6cc1a3d
Compare
|
fixed! |
haircommander
force-pushed
the
root-cgroup-no-init-1.1
branch
from
6cc1a3d to
15675a8
Compare
haircommander
force-pushed
the
root-cgroup-no-init-1.1
branch
from
8a82a42 to
9b17bdc
Compare
Sometimes, the init process is not in the root cgroup. This can be noted by GetInitPath, which already scrubs the path of `init.scope`. This was encountered when trying to patch the Kubelet to handle systemd being in a separate cpuset from root (to allow load balance disabling for containers). At present, there's no way to have libcontainer or runc manage cgroups in a hierarchy outside of the one init is in (unless the path contains `init.scope`, which is limiting) Signed-off-by: Peter Hunt <[email protected]> (cherry picked from commit 54e2021)
haircommander
force-pushed
the
root-cgroup-no-init-1.1
branch
from
9b17bdc to
10cfd81
Compare
done! |
Sometimes, the init process is not in the root cgroup. This can be noted by GetInitPath, which already scrubs the path of
init.scope.This was encountered when trying to patch the Kubelet to handle systemd being in a separate cpuset from root (to allow load balance disabling for containers). At present, there's no way to have libcontainer or runc manage cgroups in a hierarchy outside of the one init is in (unless the path contains
init.scope, which is limiting)