JDK-8333794 : New Console implementation not quitting JVM on SIGINT in containers
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 23
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • Submitted: 2024-06-07
  • Updated: 2024-06-10
  • Resolved: 2024-06-10
Related Reports
Duplicate :  
Description
I'm testing a minimal Quarkus application (a Java framework) on the very latest previews of OpenJDK 23.

When running in a shell on Fedora Linux 40, it starts fine and terminates correctly when I hit Ctrl+C (Sending SIGINT).

The same application, when running in a container based on the same Fedora 40 version, when sending SIGINT it also terminates correctly - but only when running on OpenJDK 22.

When running the same application on a freshly built preview of OpenJDK 23, SIGINT is handled correctly when running from a local shell but the signal seems ignored when running the same app within a container.

Having noticed https://bugs.openjdk.org/browse/JDK-8309155, I've experimented with -Djdk.console=java.basebroken : setting this property works around the problem and has the JVM terminate correctly.

I have to admit my "faulty" OpenJDK 23 is a custom local build; I can try to verify this with an official preview tag but having narrowed it down to being related to JDK-8309155 perhaps that's unnecessary?
Comments
Closed - many thanks [~rgiulietti] & [~alanb]!
10-06-2024

This issue was apparently a duplicate of JDK-8332921 .
07-06-2024

[~sgrinovero] I just assigned the issue to you, so you can Close it with a "Not an Issue" resolution (5th button under the title). There you can also add a comment.
07-06-2024

Awesome, I've now built the latest from branch jdk23 and can confirm that the workaround is no longer necessary: the issue was fixed already. I'm afraid I'm not an expert on the process here - could you close this issue in the appropriate way? Many thanks!
07-06-2024

Hi [~sgrinovero], yes, please try with the latest EA build from here: https://jdk.java.net/23/ and then feel free to come back with your findings. I suggest to wait for a build > 25 as soon as it becomes available, when JDK-8332921 (see [~alanb] comment) makes it into the build.
07-06-2024

Is this fixed by JDK-8332921?
07-06-2024