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 <pehunt@redhat.com>
(cherry picked from commit 54e2021)
  • Loading branch information
haircommander committed Apr 7, 2023
1 parent 9c1c844 commit 10cfd81
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 10cfd81

Please sign in to comment.