Hi, This is a bug that I witness when using java 21 on RHEL 9, RHEL 10, and fedora latest (41). It seems that the RedHat/Fedora package of java 21 does hide by default the SIGPIPE signal when running sub processes, and I can't reproduce the same behavior when trying to use openjdk 21 in an ubuntu or arch linux container. So to reproduce this issue, create a file /java-21-bug-reproducer/plop.java with this content inside a fedora system/container [root@7fb1783bf40a /]# cat /java-21-bug-reproducer/plop.java import java.io.BufferedReader; import java.io.InputStreamReader; import java.io.IOException; class TestSystemCommand { public static void main(String[] args) { try { Process process = Runtime.getRuntime().exec(args); BufferedReader reader = new BufferedReader(new InputStreamReader(process.getInputStream())); String line; while ((line = reader.readLine()) != null) { System.out.println(line); } reader.close(); } catch (IOException e) { e.printStackTrace(); } } } This is basically a java wrapper which creates a subprocess with the CLI arguments and prints the output of this subprocess. Then install both java 21 & 24: [root@7fb1783bf40a /]# dnf install -y java-21-openjdk-headless java-24-openjdk-headless And try to run the same command with both java 21 & 24. This will show the subprocess signal ignored mask: [root@7fb1783bf40a /]# /usr/lib/jvm/java-21-openjdk/bin/java /java-21-bug-reproducer/plop.java grep SigIgn /proc/self/status SigIgn: 0000000000001000 [root@7fb1783bf40a /]# /usr/lib/jvm/java-24-openjdk/bin/java /java-21-bug-reproducer/plop.java grep SigIgn /proc/self/status SigIgn: 0000000000000000 We see a different ignored signal mask with java 21 vs java 24. You can confirm this is effectively SIGPIPE by using this command: [root@7fb1783bf40a /]# grep SigIgn /proc/self/status SigIgn: 0000000000000000 [root@7fb1783bf40a /]# env --ignore-signal=SIGPIPE -- grep SigIgn /proc/self/status SigIgn: 0000000000001000 I was curious is this is a RedHat/Fedora only bug, or if this comes from upstream openjdk 21. So I tried with both an ubuntu container & an archlinux container, installing openjdk 21 in both, sharing the same /java-21-bug-reproducer volume, and here are the results: > podman run -i -t --rm --pull=always --volumes-from=7fb1783bf40a ubuntu sh -c 'apt-get update && apt-get install -y openjdk-21-jdk-headless && java /java-21-bug-reproducer/plop.java grep SigIgn /proc/self/status' ... (snapped) SigIgn: 0000000000000000 > podman run -i -t --rm --pull=always --volumes-from=7fb1783bf40a archlinux sh -c 'pacman --noconfirm -Sy jdk21-openjdk && java /java-21-bug-reproducer/plop.java grep SigIgn /proc/self/status' ... (snapped) SigIgn: 0000000000000000 Note: in practice, this behavior of openjdk 21 in RHEL/Fedora causes issues in Jenkins when using some commands which may require SIGPIPE to terminate, this was reported on Jenkins side in https://issues.jenkins.io/browse/JENKINS-75512 Cheers, Romain Reproducible: Always Actual Results: Java 21 hides SIGPIPE by default in subprocess, while java >= 22 doesn't, and this seems to be specific to RHEL/Fedora packages. Expected Results: Java 21 on RHEL/Fedora behaves as other Java >= 22 and other openjdk 21 found in other distros: SIGPIPE is not ignored by default in subprocesses.
"I was curious is this is a RedHat/Fedora only bug, or if this comes from upstream openjdk 21." But you don't actually test upstream OpenJDK 21. You test two other downstream packages and in different environments, so there are a lot of variables in play here. Have you tried building OpenJDK 21 from upstream and running it in the same RHEL or Fedora environment? How do you know if it is different for 22 and later? I only see testing of 24. The only patch we apply to java-21-openjdk in RHEL is for FIPS support. I don't know of anything that would change thia behaviour. It may be that there is something in the You don't say which Ubuntu package you tested, but I downloaded https://archive.ubuntu.com/ubuntu/pool/main/o/openjdk-21/openjdk-21_21.0.6+7-1~24.04.1.debian.tar.xz and it applies 40 patches to the upstream code.
> Have you tried building OpenJDK 21 from upstream and running it in the same RHEL or Fedora environment? No I haven't. I don't know if that's an easy task for someone like me who has no experience hacking with upstream java and local jdk builds. As another downstream test, I tested temurin 21 (installed the fedora package "adoptium-temurin-java-repository" then ran "dnf install --enablerepo=adoptium-temurin-java-repository temurin-21-jdk") and I see that temurin jdk 21 also don't ignore SIGPIPE, like ubuntu/archlinux: [root@5789044e139c /]# /usr/lib/jvm/temurin-21-jdk/bin/java /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180000000 According to https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks it's possible that in the future, at least in fedora (any maybe RHEL later ?) jdk 21 will be provided via temurin, so I guess that's still a relevant comparison with current fedora jdk 21. > How do you know if it is different for 22 and later? I only see testing of 24. I had an earlier version of RHEL 9 where we did use jdk 22 where "it worked" for us, and with jdk 21 it was failing similarly: [root@5ddeb84463bf jenkins]# rpm -qa|grep jdk copy-jdk-configs-4.0-3.el9.noarch java-latest-openjdk-headless-22.0.2.0.9-1.rolling.el9.x86_64 If you try on a "quay.io/fedora/fedora:38" OCI container right now, and if you "dnf install -y java-latest-openjdk-headless java-21-openjdk-headless" you will see this behavior: [root@7b6b9d504acb /]# /usr/lib/jvm/java-21-openjdk-21.0.3.0.9-1.fc38.x86_64/bin/java /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180001000 [root@7b6b9d504acb /]# /usr/lib/jvm/java-22-openjdk-22.0.1.0.8-1.rolling.fc38.x86_64/bin/java /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180000000
> The only patch we apply to java-21-openjdk in RHEL is for FIPS support. I don't know of anything that would change thia behaviour. Actually it may come from this fips patch which is RHEL/Fedora specific. While invesitgating with strace, comparing jdk 21 vs 24, I van see that in jdk 21 we do change the sigaction for SIGPIPE to SIG_IGN, just before reading the fips_enabled file. Here is a selected extract of strace: 252 rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f9996ce3bf0}, NULL, 8) = 0 252 openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 4 And also, if I disable fips, then the set of ignored signal changes: [root@42d30e7cc6f1 /]# /usr/lib/jvm/java-21-openjdk/bin/java /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180001000 [root@42d30e7cc6f1 /]# /usr/lib/jvm/java-21-openjdk/bin/java -Dcom.redhat.fips=false /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180000000 [root@42d30e7cc6f1 /]# /usr/lib/jvm/java-21-openjdk/bin/java -Djava.security.disableSystemPropertiesFile=true /plop.java grep SigIgn /proc/self/status SigIgn: 0000000180000000
Debugging a bit with gdb, here is the stack trace when setting the signal handler ignoring SIGPIPE: Thread 2 "java" hit Breakpoint 1, __GI___sigaction (sig=sig@entry=13, act=act@entry=0x7f7458856970, oact=oact@entry=0x0) at sigaction.c:27 27 { Missing rpms, try: dnf --enablerepo='*debug*' install nss-util-debuginfo-3.110.0-2.fc42.x86_64 (gdb) p *act $1 = {__sigaction_handler = {sa_handler = 0x1, sa_sigaction = 0x1}, sa_mask = {__val = {0, 0, 24, 0, 140137678072480, 140137678072896, 140137602395664, 140137678072288, 140137699965806, 140137678072320, 140137602220080, 140137002660462, 140137002474880, 140137678072336, 140137002298650, 140137002660462}}, sa_flags = 0, sa_restorer = 0x7f7458856a10} (gdb) bt #0 __GI___sigaction (sig=sig@entry=13, act=act@entry=0x7f7458856970, oact=oact@entry=0x0) at sigaction.c:27 #1 0x00007f74303f1258 in _PR_UnixInit () at ../../../../../nspr/pr/src/md/unix/unix.c:2626 #2 0x00007f74303def98 in _PR_InitStuff () at ../../../../nspr/pr/src/misc/prinit.c:197 #3 0x00007f74303df119 in _PR_ImplicitInitialization () at ../../../../nspr/pr/src/misc/prinit.c:201 #4 0x00007f74303de745 in PR_GetEnvSecure (var=0x7f743043726e "NSS_FIPS") at ../../../../nspr/pr/src/misc/prenv.c:87 #5 0x00007f7430429946 in NSS_GetSystemFIPSEnabled () from /lib64/libnssutil3.so #6 0x00007f74305856fa in Java_java_security_SystemConfigurator_getSystemFIPSEnabled (env=0x7f745402b1c8, cls=<optimized out>) at src/java.base/share/native/libsystemconf/systemconf.c:202 #7 0x00007f74438a59c0 in ?? () #8 0x00007f7458856be0 in ?? () #9 0x00007f73cf0b9a90 in ?? () #10 0x0000000000000003 in ?? () #11 0x00007f73cf0ba508 in ?? () #12 0x0000000000000000 in ?? () This comes from the nss code: https://github.com/nss-dev/nspr/blob/dead7133d4535bf4fade1814dd8c261c01b76635/pr/src/md/unix/unix.c#L2820 sigact.sa_handler = SIG_IGN; sigemptyset(&sigact.sa_mask); sigact.sa_flags = 0; rv = sigaction(SIGPIPE, &sigact, 0); PR_ASSERT(0 == rv); I don't know why the same doesn't happen for jdk >= 22
I guess it doesn't happen in the package "java-latest-openjdk" as the fips patch seems commented there: https://src.fedoraproject.org/rpms/java-latest-openjdk-portable/blob/rawhide/f/java-latest-openjdk-portable.spec#_696
Note: there is some discussion happening in https://issues.redhat.com/browse/OPENJDK-3829 as well, so cross-referencing it here.