8349988: Change cgroup version detection logic to not depend on /proc/cgroups

[jmtd]

This is a backport of an improvement to cgroup detection logic. This fixes mis-detection on some systems e.g. Debian and Ubuntu systems, or systems running a recent enough mainline kernel which no longer propagates the older /proc/cgroups file with necessary controllers.

This wasn't clean: there are a few nullptr to NULL substitutions (in the second commit).

I worked from Severin's 17u backport of 8349988.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8347811 needs maintainer approval
• Change must be properly reviewed (2 reviews required, with at least 2 Reviewers)
• JDK-8349988 needs maintainer approval

Issues

• JDK-8349988: Change cgroup version detection logic to not depend on /proc/cgroups (Sub-task - P3 - Requested)
• JDK-8347811: Container detection code for cgroups v2 should use cgroup.controllers (Enhancement - P3 - Requested)

Reviewers

• Paul Hohensee (@phohensee - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk11u-dev.git pull/3177/head:pull/3177
$ git checkout pull/3177

Update a local copy of the PR:
$ git checkout pull/3177
$ git pull https://git.openjdk.org/jdk11u-dev.git pull/3177/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3177

View PR using the GUI difftool:
$ git pr show -t 3177

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk11u-dev/pull/3177.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back jdowland! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issues from the original commit.

[mlbridge]

Webrevs

• 00: Full (46a204cc)

[phohensee]

Indeed clean except for nullptr -> NULL.

[openjdk]

⚠️ @jmtd This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[jmtd]

/approval request backport of an improvement to cgroup detection logic. important for newer kernels which do not populate /proc/cgroups with the required information. not clean, small number of fixups in second commit.

[openjdk]

@jmtd
8349988: The approval request has been created successfully.
8347811: The approval request has been created successfully.

[gnu-andrew]

/reviewers 2 reviewer

[openjdk]

@gnu-andrew
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 2 Reviewers).

[gnu-andrew]

This mostly looks ok. I spotted three minor issues:

• In changing the section which reads /proc/cgroups, part of JDK-8238161: "use os::fopen in HS code where possible" is inadvertently introduced by changing cgroups = fopen(proc_cgroups, "r"); to os::fopen(controllers_file, "r"). As there are no cases of os::fopen in this file in 11u at present, I would stick with fopen here rather than introducing a single usage while the rest of the file is using fopen.
• Around that same section, a double space in the comment after controllers and before If not is reduced to single. It would be good to keep this the same as 21u.
• I was confused by the copyright header change to 2025 in cgroupSubsystem_linux.cpp for some time. We don't generally update copyright headers as part of backports to reduce future friction, but this isn't that either; it's 2026 and only that one file is updated, while all are pre-2025 in 11u. Then I saw the fclose that comes from JDK-8354878 along with this header change. That needs to be credited using the issue command.

The first two of these seem to stem from the 17u backport. I didn't realise at first that I was looking at the 25u version to compare, but I think it would still be good to fix these trivial issues here, even if we're now stuck with them in the 17u backport. Clearly I didn't look at that one closely enough at the time.

The third seems to come from the fact that you referenced the 25u commit in your 'Backport x' commit and so Skara hasn't picked up the other issue. That should be easily fixed with the appropriate issue command.