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>
  • Loading branch information
haircommander committed Mar 24, 2023
1 parent efad7a3 commit bfbc355
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 @@ -271,14 +271,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 bfbc355

Please sign in to comment.