Skip to content

Commit

Permalink
libctr/cgroups: don't take init's cgroup into account
Browse files Browse the repository at this point in the history
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]>
  • Loading branch information
haircommander authored and kolyshkin committed Apr 5, 2023
1 parent 55b2dbf commit 43d85b3
Showing 1 changed file with 1 addition and 8 deletions.
9 changes: 1 addition & 8 deletions libcontainer/cgroups/systemd/v1.go
Original file line number Diff line number Diff line change
Expand Up @@ -273,14 +273,7 @@ func getSubsystemPath(slice, unit, subsystem string) (string, error) {
return "", err
}

initPath, err := cgroups.GetInitCgroup(subsystem)
if err != nil {
return "", err
}
// if pid 1 is systemd 226 or later, it will be in init.scope, not the root
initPath = strings.TrimSuffix(filepath.Clean(initPath), "init.scope")

return filepath.Join(mountpoint, initPath, slice, unit), nil
return filepath.Join(mountpoint, slice, unit), nil
}

func (m *legacyManager) Freeze(state configs.FreezerState) error {
Expand Down

0 comments on commit 43d85b3

Please sign in to comment.