Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1251014 > unrolled thread

Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Harald Dunkel <harri@afaics.de> - 2025-06-25 09:10 +0200
    Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-06-26 18:30 +0200
      Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-06-26 19:20 +0200
        Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-07-09 00:50 +0200
          Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-07-09 14:00 +0200
      Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Harald Dunkel <harri@afaics.de> - 2025-06-26 20:50 +0200
        Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-06-29 14:30 +0200
    Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Ben Hutchings <ben@decadent.org.uk> - 2025-06-26 18:50 +0200
    Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21 Bastian Blank <waldi@debian.org> - 2025-06-26 20:30 +0200
    Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups Harald Dunkel <harri@afaics.de> - 2025-07-14 08:30 +0200
    Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups Harald Dunkel <harald.dunkel@aixigo.com> - 2025-07-21 10:00 +0200
      Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups Salvatore Bonaccorso <carnil@debian.org> - 2025-07-27 17:00 +0200

#1251014 — Bug#1108294: kernel 6.12 breaks cgroup awareness of openjdk 21

Package: linux-image-6.12.33+deb13-amd64
Version: 6.12.33-1

By default kernel 6.12 dropped some deprecated features around cgroupv2
support. This affects openjdk 21 and older, see

	https://bugs.openjdk.org/browse/JDK-8347811
	https://bugs.debian.org/1107967

This is fatal: Using cgroupv2 openjdk 21 doesn't recognize the container
limits by default anymore, the Java GC is not run since there seems to
be plenty of memory, and the Java app runs into the container's memory
limit and is killed with OOM.

openjdk 25 has been fixed, AFAICT.

Workaround is to configure the kernel with

	CONFIG_CPUSETS_V1=y
	CONFIG_MEMCG_V1=y

to bring back the deprecated features.

I would like to suggest to re-enable the deprecated features in the
kernel. It is pretty much unlikely that openjdk 21 is fixed in time
for Trixie. Not to mention the kernel backport to Bookworm.


Regards
Harri

[toc] | [next] | [standalone]

#1251140

[Multipart message — attachments visible in raw view] — view raw

On Wed, 25 Jun 2025 08:33:24 +0200 Harald Dunkel <harri@afaics.de>
wrote:
> Package: linux-image-6.12.33+deb13-amd64
> Version: 6.12.33-1
> 
> By default kernel 6.12 dropped some deprecated features around
cgroupv2
> support. This affects openjdk 21 and older, see
> 
>       https://bugs.openjdk.org/browse/JDK-8347811
>       https://bugs.debian.org/1107967
> 
> This is fatal: Using cgroupv2 openjdk 21 doesn't recognize the
container
> limits by default anymore, the Java GC is not run since there seems to
> be plenty of memory, and the Java app runs into the container's memory
> limit and is killed with OOM.
> 
> openjdk 25 has been fixed, AFAICT.
> 
> Workaround is to configure the kernel with
> 
>       CONFIG_CPUSETS_V1=y
>       CONFIG_MEMCG_V1=y
> 
> to bring back the deprecated features.
> 
> I would like to suggest to re-enable the deprecated features in the
> kernel. It is pretty much unlikely that openjdk 21 is fixed in time
> for Trixie. Not to mention the kernel backport to Bookworm.

Thank you for bringing this to our attention.

I don't think it makes sense for us to re-enable cgroups v1, given that
it has been deprecated for so long and OpenJDK itself can use v2.

I will look into whether we can instead provide only a /proc/cgroups
file, which seems to be all that OpenJDK actually needed.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[toc] | [prev] | [next] | [standalone]

#1251154

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2025-06-26 at 18:24 +0200, Ben Hutchings wrote:
[...]
> Thank you for bringing this to our attention.
> 
> I don't think it makes sense for us to re-enable cgroups v1, given that
> it has been deprecated for so long and OpenJDK itself can use v2.
> 
> I will look into whether we can instead provide only a /proc/cgroups
> file, which seems to be all that OpenJDK actually needed.

In fact this may be as simple as reverting:

commit af000ce85293b8e608f696f0c6c280bc3a75887f
Author: Michal Koutný <mkoutny@suse.com>
Date:   Mon Sep 9 18:32:23 2024 +0200
 
    cgroup: Do not report unavailable v1 controllers in /proc/cgroups

but I have not yet tested that.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[toc] | [prev] | [next] | [standalone]

#1252207

[Multipart message — attachments visible in raw view] — view raw

Control: tag -1 patch

On Thu, 2025-06-26 at 19:17 +0200, Ben Hutchings wrote:
> On Thu, 2025-06-26 at 18:24 +0200, Ben Hutchings wrote:
> [...]
> > Thank you for bringing this to our attention.
> > 
> > I don't think it makes sense for us to re-enable cgroups v1, given that
> > it has been deprecated for so long and OpenJDK itself can use v2.
> > 
> > I will look into whether we can instead provide only a /proc/cgroups
> > file, which seems to be all that OpenJDK actually needed.
> 
> In fact this may be as simple as reverting:
> 
> commit af000ce85293b8e608f696f0c6c280bc3a75887f
> Author: Michal Koutný <mkoutny@suse.com>
> Date:   Mon Sep 9 18:32:23 2024 +0200
>  
>     cgroup: Do not report unavailable v1 controllers in /proc/cgroups
> 
> but I have not yet tested that.

Yes, this seems to work.

I compiled the following class:

--- BEGIN ---
import java.lang.System;

class Main {
    public static void main(String[] args) {
	int count = Integer.parseInt(args[0]);
	char[] one_mb;
	int i;

	for (i = 0; i != count; i++) {
	    one_mb = new char[0x100000];
	    System.out.println(one_mb[0] | one_mb[0xfffff]);
	}
    }
};
--- END ---

and ran it with an argument of "1000".

I used a podman container of Debian limited to 50 MiB.  With the current
kernel from trixie, it OOMs.  With that commit reverted, it runs to
completion.

I will open an MR tomorrow.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#1252235

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2025-07-09 at 00:46 +0200, Ben Hutchings wrote:
[...]
> I will open an MR tomorrow.

Opened <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1572>.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.

[toc] | [prev] | [next] | [standalone]

#1251163

Ben Hutchings wrote:
> 
> Thank you for bringing this to our attention.
> 
> I don't think it makes sense for us to re-enable cgroups v1, given that
> it has been deprecated for so long and OpenJDK itself can use v2.
> 

You are right, it's been deprecated for quite some time, and this is
clearly a bug in openjdk, but currently there is no better version of
JDK21. I am not sure what you mean by "OpenJDK itself can use v2".

> I will look into whether we can instead provide only a /proc/cgroups
> file, which seems to be all that OpenJDK actually needed.
> 

How is this supposed to work? Since we are talking about the host system
here you cannot know how /proc was mounted in the container, which
Container framework is involved, or whether the container is based on
Debian at all.

[toc] | [prev] | [next] | [standalone]

#1251387

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2025-06-26 at 20:40 +0200, Harald Dunkel wrote:
> Ben Hutchings wrote:
> > 
> > Thank you for bringing this to our attention.
> > 
> > I don't think it makes sense for us to re-enable cgroups v1, given that
> > it has been deprecated for so long and OpenJDK itself can use v2.
> > 
> 
> You are right, it's been deprecated for quite some time, and this is
> clearly a bug in openjdk, but currently there is no better version of
> JDK21. I am not sure what you mean by "OpenJDK itself can use v2".

OpenJDK (from v11 onwards) appears to use v2 of the cgroups API if
available, and only mistakenly relied on /proc/cgroups for detection of
which controllers are enabled.

> > I will look into whether we can instead provide only a /proc/cgroups
> > file, which seems to be all that OpenJDK actually needed.
> > 
> 
> How is this supposed to work? Since we are talking about the host system
> here you cannot know how /proc was mounted in the container, which
> Container framework is involved, or whether the container is based on
> Debian at all.

We have to assume that /proc/cgroups and cgroupfs are exposed to the
container, otherwise none of this detection could have worked before...

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[toc] | [prev] | [next] | [standalone]

#1251151

[Multipart message — attachments visible in raw view] — view raw

For reference, I think this is the status of the OpenJDK versions in the
archive:

           | Debian release     | cgroups |
           | 11 | 12 | 13 | sid | support |
-----------+----+----+----+-----+---------+
openjdk-8  |    |    |    | X   | no      |
openjdk-11 | X  |    |    | X   | yes *   |
openjdk-17 | X  | X  |    | X   | yes *   |
openjdk-21 |    |    | X  | X   | yes *   |
openjdk-22 |    |    |    | X   | yes *   |
openjdk-23 |    |    |    | X   | yes *   |
openjdk-24 |    |    |    | X   | yes *   |
openjdk-25 |    |    | X  | X   | yes +   |

* CgroupSubsystemFactory depends on /proc/cgroups even if using v2
+ C++ implementation of CgroupSubsystemFactory does not depend on
  /proc/cgroups if using v2, but Java implementation still does

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.

[toc] | [prev] | [next] | [standalone]

#1251158

On Wed, Jun 25, 2025 at 08:33:24AM +0200, Harald Dunkel wrote:
> This is fatal: Using cgroupv2 openjdk 21 doesn't recognize the container
> limits by default anymore, the Java GC is not run since there seems to
> be plenty of memory, and the Java app runs into the container's memory
> limit and is killed with OOM.
> openjdk 25 has been fixed, AFAICT.

Did you think about backporting those changes?

Bastian

-- 
It is necessary to have purpose.
		-- Alice #1, "I, Mudd", stardate 4513.3

[toc] | [prev] | [next] | [standalone]

#1252688 — Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

I booted the new kernel this morning. Using cgroupv2 I got

% docker run -it --rm -m 4g --cpus=3 debian:trixie 
root@b46ebbb70b04:/# apt update
Get:1 http://deb.debian.org/debian trixie InRelease [168 kB]
Get:2 http://deb.debian.org/debian trixie-updates InRelease [45.1 kB]
Get:3 http://deb.debian.org/debian-security trixie-security InRelease [43.4 kB]
Get:4 http://deb.debian.org/debian trixie/main amd64 Packages [9672 kB]
Get:5 http://deb.debian.org/debian-security trixie-security/main amd64 Packages [5304 B]
Fetched 9934 kB in 1s (9313 kB/s)                    
13 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@b46ebbb70b04:/# apt -y install default-jdk
:
:
root@b46ebbb70b04:/# java -Xlog:os+container=trace --version
[0.001s][trace][os,container] OSContainer::init: Initializing Container Support
[0.001s][debug][os,container] Detected optional cpuset controller entry in /proc/cgroups
[0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.002s][debug][os,container] Detected cgroups v2 unified hierarchy
[0.002s][trace][os,container] Path to /cpu.max is /sys/fs/cgroup/cpu.max
[0.002s][trace][os,container] Raw value for CPU quota is: 300000
[0.002s][trace][os,container] CPU Quota is: 300000
[0.002s][trace][os,container] Path to /cpu.max is /sys/fs/cgroup/cpu.max
[0.002s][trace][os,container] CPU Period is: 100000
[0.002s][trace][os,container] CPU Quota count based on quota/period: 3
[0.002s][trace][os,container] OSContainer::active_processor_count: 3
[0.002s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 3
[0.002s][trace][os,container] total physical memory: 67099267072
[0.002s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max
[0.002s][trace][os,container] Raw value for memory limit is: 4294967296
[0.002s][trace][os,container] Memory Limit is: 4294967296
[0.004s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 3
[0.027s][trace][os,container] Path to /cpu.max is /sys/fs/cgroup/cpu.max
[0.027s][trace][os,container] Raw value for CPU quota is: 300000
[0.027s][trace][os,container] CPU Quota is: 300000
[0.027s][trace][os,container] Path to /cpu.max is /sys/fs/cgroup/cpu.max
[0.027s][trace][os,container] CPU Period is: 100000
[0.027s][trace][os,container] CPU Quota count based on quota/period: 3
[0.027s][trace][os,container] OSContainer::active_processor_count: 3
openjdk 21.0.7 2025-04-15
OpenJDK Runtime Environment (build 21.0.7+6-Debian-1)
OpenJDK 64-Bit Server VM (build 21.0.7+6-Debian-1, mixed mode, sharing)


This looks as expected. CPU and memory limits are correct. Now I have
to wait for a backport for Bookworm to roll out the new kernel to our
developers and to our Kubernetes nodes.


Thank you very much. I highly appreciate your contribution to
Debian.


Harri

[toc] | [prev] | [next] | [standalone]

#1253454 — Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

> Applied to cgroup/for-6.17.

I would recommend to follow upstream for kernels beyond
Trixie in this aspect. Debian needs a workaround for kernel
6.12 in Trixie, because there are no JDKs fully compatible
with cgroupv2 yet, including the brand-new

	OpenJDK 11.0.28
        OpenJDK 17.0.16
        OpenJDK 21.0.8

released a few days ago. I expect the JDKs will be fixed for
Forky.

Just my $0.02 of course. Regards
Harri

[toc] | [prev] | [next] | [standalone]

#1254052 — Bug#1108294: [PATCH 4/4] cgroup: Do not report unavailable v1 controllers in /proc/cgroups

Hi,

On Mon, Jul 21, 2025 at 09:42:23AM +0200, Harald Dunkel wrote:
> > Applied to cgroup/for-6.17.
> 
> I would recommend to follow upstream for kernels beyond
> Trixie in this aspect. Debian needs a workaround for kernel
> 6.12 in Trixie, because there are no JDKs fully compatible
> with cgroupv2 yet, including the brand-new
> 
> 	OpenJDK 11.0.28
>         OpenJDK 17.0.16
>         OpenJDK 21.0.8
> 
> released a few days ago. I expect the JDKs will be fixed for
> Forky.

This would be my "personal" (in terms of keeping deltas in the
packaging) preference:
- make sure the patches get backported down to 6.12.y
- drop our local revert
- make uses affected made aware of the kernel parameter to use (maybe
  via a NEWS entry?)

I had a short discussion on IRC with Ben about that, and as the
upstream changes are not yet down to 6.12.y the situation is rather
clear that we have the revert. If the changes goes down to 6.12.y
though I would love to rediscuss if we could consider the above
instread.

I though realize it is too early to at all consider, given it's not
yet applied upsream.

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web