Prepare for cgroup v2-only mode (Ubuntu 26.04)

[richlander]

Ubuntu 26.04 is perhaps the first distro to remove cgroup v1 support. I doubt that is interesting. I could imagine some code that assumed the presence of cgroup v1 and treated v2 as light-up.

Source: https://linuxconfig.org/ubuntu-26-04-release-date-and-new-features-in-resolute-raccoon

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[richlander]

Note

This comment was AI/Copilot-generated.

I did a repo scan plus a quick check of the .NET 11 support matrix. Current status:

Product readiness

• I did not find code that assumes cgroup v1 must exist. The relevant codepaths are version-aware and already have explicit v2 handling in:
  • src/libraries/Common/src/Interop/Linux/cgroups/Interop.cgroups.cs
  • src/coreclr/gc/unix/cgroup.cpp
  • src/coreclr/pal/src/misc/cgroup.cpp
  • src/coreclr/nativeaot/Runtime/unix/cgroupcpu.cpp
  • src/mono/mono/utils/mono-cgroup.c
• Those paths detect v1 vs v2 and use the expected v2 files (memory.max, memory.current, cpu.max) when running in cgroup v2.
• So from a product perspective, things look ready for v1-only, v1+v2 (hybrid), and v2-only environments. I don’t see an obvious repo-level blocker for v2-only.

Test / coverage readiness

• We already have unit coverage for both v1 and v2 formats in src/libraries/Common/tests/Tests/Interop/cgroupsTests.cs.
• We also have some indirect smoke coverage via runtime/process tests (for example, Process.MaxWorkingSet) and runtime info logging.
• I did not find any test that specifically depends on a v1-only machine.
• The current gap is real-host v2-only validation. Most of the existing tests are parser/fallback oriented, not end-to-end assertions on a kernel where cgroup v1 is actually unavailable.

Since cgroup is a host concept, this probably won’t materially affect CI until Helix runs on real 26.04 (or similar) hosts. The container image names in queue strings are not, by themselves, proof of v2-only coverage.

Status by environment type

• v1-only: no new concern found; existing codepaths still support it.
• v1+v2 / hybrid: current code and existing tests appear fine.
• v2-only: product looks ready, but CI confidence will really improve once we have actual v2-only hosts in the test fleet.

.NET 11 support burden

Per ~/git/core/release-notes/11.0/supported-os.md, .NET 11 preview currently supports a fairly broad Linux set, including:

• Ubuntu 26.04, 25.10, 24.04, 22.04
• RHEL 10, 9, 8 and CentOS Stream 10, 9
• SLES 16.0, 15.7
• Debian 13
• Fedora 43
• openSUSE Leap 16.0
• Azure Linux 3.0
• Alpine 3.23, 3.22

That means for .NET 11 we should plan for a mixed cgroup landscape for some time:

• v2-only becomes more important with newer distros like Ubuntu 26.04
• v1+v2 / hybrid is still plausible across the broader supported Linux matrix
• v1-only is less important as a CI target, but I wouldn’t intentionally drop product compatibility while older supported distros remain in the support set

Suggested next step

Once 26.04 hosts are available, I’d make sure we have at least one libraries lane and one CoreCLR/runtime lane running there, and then consider adding 1-2 targeted Linux end-to-end tests for v2-limited memory / CPU behavior if we want stronger real-host coverage.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[richlander]

FYI: There is no rush on this until we have Ubuntu 26.04 VMs ready.