common: remove Cgroups v1 support (podman6) #387

lsm5 · 2025-10-10T14:33:11Z

Resolves: RUN-3567 (partly)

podmanbot · 2025-10-10T14:34:26Z

✅ A new PR has been created in buildah to vendor these changes: containers/buildah#6423

lsm5 · 2025-10-10T14:38:54Z

@containers/container-libs-maintainers I think it'd be nice to have a podman6 or cgv1 or some such label here as well. Mind creating one please?

lsm5 · 2025-10-10T14:45:35Z

ah if it's manual merges here, then no need I guess.

Luap99 · 2025-10-10T14:49:43Z

yeah manual merge, keep the PR as draft until we branched.

Still a label to track all the things is still a good idea so I added the "podman 6" label.

mtrmac

I know absolutely nothing about the problem space, this is just looking at the diff + immediately surrounding code.

mtrmac · 2025-10-13T17:53:05Z

common/pkg/cgroups/cgroups_linux.go

 // Load loads an existing cgroup control.
 func Load(path string) (*CgroupControl, error) {
-	cgroup2, err := IsCgroup2UnifiedMode()
+	_, err := IsCgroup2UnifiedMode()


There are several other callers of this, and quite a few code paths that could potentially be deleted if this never returns false, nil. Do we want to update those as well? If not, what’s the exact scope of changes we do want to make?

Assuming we do change all of the callers to expect (_, err) or (true, nil), should wereplace the IsCgroup2UnifiedMode function by a function with some other name (IsProcCgroupMounted???), or perhaps remove it entirely?

But then again, note that non-Linux code is hard-coded to return (false, nil). Is that still what we want?

On #podman-dev matrix , there seemed to be agreement on having a single check for v1/v2 in main and removing everything else. Would that suffice for the common library too? So, basically remove all cgroup conditionals and v1 logic from the library and let the library users handle this via a single check (?).

common/pkg/cgroups/cgroups_linux.go

TomSweeneyRedHat · 2025-10-15T13:24:34Z

Looks like a good start to me @lsm5

packit-as-a-service · 2025-10-21T18:04:52Z

Packit jobs failed. @containers/packit-build please check.

packit-as-a-service · 2025-10-21T18:04:53Z

Packit jobs failed. @containers/packit-build please check.

packit-as-a-service · 2025-10-21T18:04:53Z

Packit jobs failed. @containers/packit-build please check.

packit-as-a-service · 2025-10-21T18:04:53Z

Packit jobs failed. @containers/packit-build please check.

lsm5 · 2025-10-23T14:06:18Z

@containers/container-libs-maintainers Now that podman v5.7 is branched, when can we start merging v6 stuff in container-libs? I can remove draft status on this whenever we're ready to review/merge.

Removes all conditionals for IsCgroup2UnifiedMode and cgroupv2.Enabled and assumes Cgroups v2. Also removes `cgroup2` and `additionalControllers` from CgroupControl struct and all the conditionals resulting from it. pkg/cgroups.IsCgroup2UnifiedMode is being retained as it will be used in the dependent tools as a single check for v1/v2. Fixes: RUN-3567 (partly) Signed-off-by: Lokesh Mandvekar <[email protected]>

mheon · 2025-10-23T15:19:42Z

Only remaining question is whether we wait for the 6.0.0-dev bump... I think that's not really necessary though. Should be fine to un-draft

lsm5 · 2025-10-23T15:36:11Z

@containers/container-libs-maintainers PTAL

lsm5 · 2025-10-23T15:38:49Z

buildah PR: containers/buildah#6424
podman PR: containers/podman#27271

Luap99 · 2025-10-23T16:27:23Z

common/pkg/cgroups/blkio_linux.go

-		return false, nil
-	}
-	return ctr.createCgroupDirectory(Blkio)
+	return false, nil


if this function does nothing it should be removed

That might not be possible with the controllerHandler abstraction… but then all Destroy callbacks do something with a getCgroupv1Path, so there might be more opportunities to simplify.

After this PR, don’t all the Apply calls do exatly the same fs2.NewManager().Set() call? Does that do anything (well, does that do anything beneficial) to call that repeatedly?

I’m starting to have a vague impression that all of pkg/cgroups would be best replaced by direct calls of opencontainers/cgroups/fs2 — but I did not research that, and this is not the PR to do that. (It might not even be the PR to drop the controllerHandler abstraction, I have no opinion on that part.)

Luap99 · 2025-10-23T16:29:16Z

common/pkg/cgroups/cpu_linux.go

-		return false, nil
-	}
-	return ctr.createCgroupDirectory(CPU)
+	return false, nil


here as well it seem like we can remove this function

Luap99 · 2025-10-23T16:29:33Z

common/pkg/cgroups/memory_linux.go

-		return false, nil
-	}
-	return ctr.createCgroupDirectory(Memory)
+	return false, nil


Luap99 · 2025-10-23T16:33:57Z

common/pkg/config/systemd.go

 	}
-	enabled, err := cgroupv2.Enabled()
-	if err == nil && !enabled && unshare.IsRootless() {
+	if unshare.IsRootless() {


That seem wrong, the condition was if cgroupv1 && rootless I think, now it is just rootless which means we default to cgroupfs which sounds wrong and I would expect test failures because of that. I would assume this entire branch should just be deleted

Luap99 · 2025-10-23T16:37:03Z

common/pkg/sysinfo/sysinfo_linux.go

 		sysInfo.cgroupCPUInfo = checkCgroupCPU(cgMounts, quiet)
 		sysInfo.cgroupBlkioInfo = checkCgroupBlkioInfo(cgMounts, quiet)
 		sysInfo.cgroupCpusetInfo = checkCgroupCpusetInfo(cgMounts, quiet)
-		sysInfo.cgroupPids = checkCgroupPids(cgMounts, quiet)


isn't this removing PidsLimit: true which was set before when cgroupv2 is used?

well, lint didn't complain about it earlier. Looks like it can be removed. So, just to confirm, should GetDefaultPidsLimit assume PidsLimit: true and just return 4096?`

mtrmac

Just a local review looking at the package.

I’d find refactoring easier to review (and much safer to later find bugs in, via git bisect) if they were split into smaller commits, one idea at a time) — at least, please do so if you follow up on some of the newly available options pointed out below.

I’m overall unclear on the error handling — do we need to worry about e.g. /sys not being mounted at all, and IsCgroup2UnifiedMode returning (false, error) in such a situation — and that the reported errors are reasonable even after we remove the IsCgroup2UnifiedMode calls? Or is that something that we don’t care about (or perhaps something that can never happen)?

mtrmac · 2025-10-23T18:43:17Z

common/pkg/cgroups/cgroups_linux.go

-			name:    name,
-			symlink: !fileInfo.IsDir(),
+			name:    controllerName,
+			symlink: false,


symlink is always false (and never read?)

… and then I think the only remaining caller only extracts the name field, so maybe the whole controller type can be removed.

mtrmac · 2025-10-23T18:50:49Z

common/pkg/cgroups/cgroups_linux.go

 }

 // AddPid moves the specified pid to the cgroup.
 func (c *CgroupControl) AddPid(pid int) error {


pid is not used, how does this work?! (I can’t see a Podman caller)

mtrmac · 2025-10-23T18:55:48Z

common/pkg/cgroups/systemd_linux.go

-		} else {
-			ioString = "BlockIOAccounting"
-		}
+		ioString := "IOAccounting"


This can be inlined into the only user.

(Some similar opportunities exist elsewhere.)

mtrmac · 2025-10-23T18:57:02Z

common/pkg/cgroups/systemd_linux.go

 		}

-		uMap, sMap, bMap, iMap, structMap, err := resourcesToProps(resources, v2)
+		uMap, sMap, bMap, iMap, structMap, err := resourcesToProps(resources, true)


This is the only caller, the v2 parameter can removed and the function simplified.

mtrmac · 2025-10-23T19:00:12Z

common/pkg/config/default.go

 	}

-	cgroupNS := "host"
-	if cgroup2, _ := cgroupv2.Enabled(); cgroup2 {


cgroupv2.Enabled seems to be exactly the same code as cgroup.IsCgroup2UnifiedMode. Can one of the two be entirely removed?

mtrmac · 2025-10-23T19:00:41Z

common/pkg/config/default.go

-	if cgroup2, _ := cgroupv2.Enabled(); cgroup2 {
-		cgroupNS = "private"
-	}
+	cgroupNS := "private"


This can be inlined into the only user.

lsm5 · 2025-10-24T17:54:43Z

I’d find refactoring easier to review (and much safer to later find bugs in, via git bisect) if they were split into smaller commits, one idea at a time) — at least, please do so if you follow up on some of the newly available options pointed out below.

I think I could do that even for the existing stuff. Will reorganize this soon.

github-actions bot added the common Related to "common" package label Oct 10, 2025

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 10, 2025

dnm: Vendor changes from containers/container-libs#387

8b73e6f

podmanbot mentioned this pull request Oct 10, 2025

Sync: common: remove Cgroups v1 support (podman6) containers/buildah#6423

Draft

lsm5 changed the title ~~common: remove Cgroups v1 support~~ common: remove Cgroups v1 support (podman6) Oct 10, 2025

Luap99 added the podman 6 breaking changes that should go only into podman 6 only label Oct 10, 2025

lsm5 force-pushed the podman6-no-cgv1 branch from af5c8b5 to f0ba04e Compare October 10, 2025 14:57

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 10, 2025

dnm: Vendor changes from containers/container-libs#387

8a616d0

mtrmac reviewed Oct 13, 2025

View reviewed changes

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 14, 2025

dnm: Vendor changes from containers/container-libs#387

5140427

lsm5 force-pushed the podman6-no-cgv1 branch from 342d828 to 49ab99d Compare October 14, 2025 18:47

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 14, 2025

dnm: Vendor changes from containers/container-libs#387

8c19554

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 14, 2025

dnm: Vendor changes from containers/container-libs#387

0399af8

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 16, 2025

dnm: Vendor changes from containers/container-libs#387

7fddcd5

lsm5 force-pushed the podman6-no-cgv1 branch from 9406e65 to b41c3b4 Compare October 16, 2025 19:57

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 16, 2025

dnm: Vendor changes from containers/container-libs#387

79f3177

lsm5 force-pushed the podman6-no-cgv1 branch from b41c3b4 to aeb6730 Compare October 16, 2025 21:15

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 16, 2025

dnm: Vendor changes from containers/container-libs#387

c0d7e6c

lsm5 force-pushed the podman6-no-cgv1 branch from aeb6730 to 417ec98 Compare October 16, 2025 21:19

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 16, 2025

dnm: Vendor changes from containers/container-libs#387

0b82c15

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 17, 2025

dnm: Vendor changes from containers/container-libs#387

9d9c9ba

lsm5 force-pushed the podman6-no-cgv1 branch from 8305706 to 9613865 Compare October 17, 2025 13:41

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 17, 2025

dnm: Vendor changes from containers/container-libs#387

c4bbe36

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 17, 2025

dnm: Vendor changes from containers/container-libs#387

56896e4

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 17, 2025

dnm: Vendor changes from containers/container-libs#387

df949d2

lsm5 force-pushed the podman6-no-cgv1 branch from 19a1ed8 to e63ca54 Compare October 17, 2025 19:12

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 17, 2025

dnm: Vendor changes from containers/container-libs#387

adae63c

lsm5 force-pushed the podman6-no-cgv1 branch from e63ca54 to 76ae706 Compare October 21, 2025 18:02

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 21, 2025

dnm: Vendor changes from containers/container-libs#387

0c16a58

lsm5 force-pushed the podman6-no-cgv1 branch from 76ae706 to fcafd25 Compare October 21, 2025 18:04

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 21, 2025

dnm: Vendor changes from containers/container-libs#387

b9ad69e

lsm5 mentioned this pull request Oct 22, 2025

[WIP] Remove CNI for podman6 #412

Draft

lsm5 force-pushed the podman6-no-cgv1 branch from fcafd25 to 2c7c0ea Compare October 23, 2025 14:53

podmanbot pushed a commit to podmanbot/buildah that referenced this pull request Oct 23, 2025

dnm: Vendor changes from containers/container-libs#387

2d608ed

lsm5 marked this pull request as ready for review October 23, 2025 15:35

Luap99 reviewed Oct 23, 2025

View reviewed changes

lsm5 marked this pull request as draft October 23, 2025 18:38

mtrmac reviewed Oct 23, 2025

View reviewed changes

lsm5 mentioned this pull request Oct 24, 2025

[WIP] common: remove cgv1 (reattempt with finer commits) #417

Open

common: remove Cgroups v1 support (podman6) #387

Are you sure you want to change the base?

common: remove Cgroups v1 support (podman6) #387

Uh oh!

Conversation

lsm5 commented Oct 10, 2025

Uh oh!

podmanbot commented Oct 10, 2025

Uh oh!

lsm5 commented Oct 10, 2025

Uh oh!

lsm5 commented Oct 10, 2025

Uh oh!

Luap99 commented Oct 10, 2025

Uh oh!

mtrmac left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TomSweeneyRedHat commented Oct 15, 2025

Uh oh!

packit-as-a-service bot commented Oct 21, 2025

Uh oh!

packit-as-a-service bot commented Oct 21, 2025

Uh oh!

packit-as-a-service bot commented Oct 21, 2025

Uh oh!

packit-as-a-service bot commented Oct 21, 2025

Uh oh!

lsm5 commented Oct 23, 2025

Uh oh!

mheon commented Oct 23, 2025

Uh oh!

lsm5 commented Oct 23, 2025

Uh oh!

lsm5 commented Oct 23, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mtrmac left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lsm5 commented Oct 24, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

mtrmac left a comment •

edited

Loading