JDK-8253939 : [TESTBUG] Increase coverage of the cgroups detection code
  • Type: Bug
  • Component: core-libs
  • Affected Version: 15,16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: generic
  • Submitted: 2020-10-02
  • Updated: 2022-12-15
  • Resolved: 2020-10-28
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 16 Other
11.0.16Fixed 16 b22Fixed openjdk8u372Fixed
Related Reports
Relates :  
JDK-8254854 - [cgroups v1] Metric limits not properly detected on some join controller combinations
Relates :  
JDK-8253435 - Cgroup: 'stomping of _mount_path' crash if manually mounted cpusets exist
Relates :  
JDK-8252359 - HotSpot Not Identifying it is Running in a Container
Relates :  
JDK-8217766 - Container Support doesn't work for some Join Controllers combinations
Description
With JDK-8253435 and JDK-8252359 some more bugs got discovered in the container detection code: cgroups v1 vs. cgroups v2. For those fixes, regression tests got added for the hotspot code.

Also, JDK-8217766 got created without a regression test which now should be possible so as to prevent bugs like JDK-8254854.

We should have proper tests so this doesn't regress some weird corner case in some future refactoring.
Comments
Fix Request (8u) Please consider this backport to jdk8u-dev for cgroups v2 support. It's not clean: several Files.writeString → Files.write(…,.getBytes()) changes needed. Thanks
15-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk8u-dev/pull/169 Date: 2022-11-14 10:19:29 +0000
14-11-2022
Fix Request (11u) Please approve backporting this to 11u as part of cgroupsv2 support. Applies clean, touches two tests which pass on my cgroups v2 system. This depends on JDK-8245543 being backported first (GitHub PR #994) Thanks!
05-04-2022
A pull request was submitted for review. URL: https://git.openjdk.java.net/jdk11u-dev/pull/1001 Date: 2022-04-05 08:55:29 +0000
05-04-2022
Changeset: 42fc1589 Author: Severin Gehwolf <sgehwolf@openjdk.org> Date: 2020-10-28 18:54:02 +0000 URL: https://git.openjdk.java.net/jdk/commit/42fc1589
28-10-2020
Consider a hypothetical /proc/self/mountinfo like this: 42 30 0:38 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime shared:14 - cgroup none rw,seclabel,cpuset 121 32 0:37 / /cpuset rw,relatime shared:69 - cgroup none rw,cpuset Then, the Java metrics code from CgroupV1Subsystem.java would parse this as follows: try (Stream<String> lines = CgroupUtil.readFilePrivileged(Paths.get("/proc/self/mountinfo"))) { lines.filter(line -> line.contains(" - cgroup ")) .map(line -> line.split(" ")) .forEach(entry -> createSubSystemController(subsystem, entry)); where createSubSystemController() looks like: if (mountentry.length < 5) return; Path p = Paths.get(mountentry[4]); String[] subsystemNames = p.getFileName().toString().split(","); for (String subsystemName: subsystemNames) { switch (subsystemName) { case "memory": subsystem.setMemorySubSystem(new CgroupV1MemorySubSystemController(mountentry[3], mountentry[4])); break; case "cpuset": subsystem.setCpuSetController(new CgroupV1SubsystemController(mountentry[3], mountentry[4])); break; case "cpuacct": subsystem.setCpuAcctController(new CgroupV1SubsystemController(mountentry[3], mountentry[4])); break; case "cpu": subsystem.setCpuController(new CgroupV1SubsystemController(mountentry[3], mountentry[4])); break; case "blkio": subsystem.setBlkIOController(new CgroupV1SubsystemController(mountentry[3], mountentry[4])); break; default: // Ignore subsystems that we don't support break; } } That is, subsystem.setCpuSetController(new CgroupV1SubsystemController(mountentry[3], mountentry[4])) will be called twice and the later cpuset entry wins. So it would use root="/" and mountpoint="/cpuset", rather than the more likely candidate of root="/", mountpoint="/sys/fs/cgroup/cpuset". This would go unnoticed in the majority of cases (where no such second mount entry for /cpuset exists), but can cause subtle bugs in some cases. Unfortunately this isn't easily testable without also implementing JDK-8254001.
12-10-2020
JDK-8253435 didn't include this after all. Reopening.
09-10-2020
This one will be fixed with JDK-8245543 as it'll need adequate coverage.
06-10-2020
https://github.com/jerboaa/jdk/commit/315ef40fcbbb6b41be1cbf25f5b9d0245dce0cd1
02-10-2020