A customer reports an error where a well-known system library, upon loading into the JVM process (via a longish indirect dependency chain), changes the signal disposition of the process for SIGPIPE to SIG_IGN. This gets inherited down to child processes, where it causes child processes to not react to SIGPIPE.
The system library is clearly at fault here, but the current workaround we employ (pre-loading libjsig to correct changed signals) is cumbersome and costly for customers. It requires analysis and good OS knowledge. It is an okay solution for special cases where the customer themselves have unorthodox signal requirements; but as a general solution for badly behaved system libraries, this is not practical.
See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html
The behavior should be changed such that we set SIGPIPE to SIG_DFL in the child processes.
The system library is clearly at fault here, but the current workaround we employ (pre-loading libjsig to correct changed signals) is cumbersome and costly for customers. It requires analysis and good OS knowledge. It is an okay solution for special cases where the customer themselves have unorthodox signal requirements; but as a general solution for badly behaved system libraries, this is not practical.
See further details and arguments for the fix in this mail thread: https://mail.openjdk.org/pipermail/core-libs-dev/2025-April/144077.html
The behavior should be changed such that we set SIGPIPE to SIG_DFL in the child processes.
- links to
-
Commit(master) openjdk/jdk/bdb1646a
-
Review(master) openjdk/jdk/26615