Runtime.exec and SIGPIPE + SIG_IGN

[Archie Cobbs]

On Tue, Apr 29, 2025 at 9:55 AM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> 1) In a scenario like the one I described we start java, it installs the
> SIGPIPE handler, which then gets preplaced by the third-party lib with
> SIG_IGN, resulting in child processes running with SIG_IGN for SIGPIPE.
> 2) If, however,r the libjvm.so gets embedded into a custom launcher, which
> already had set SIG_IGN for SIGPIPE, the JVM will replace that handler with
> its own, resulting in child processes running with SIG_DFL.
>
> This seems a bit arbitrary to me and seems to support the view that this
> behavior is not intended.
>

Agreed - water appearing randomly in the bottom of your boat is usually
evidence of a leak somewhere :)

Shouldn't the environment of a new child process created via Runtime.exec()
be the same no matter when or how it was created? Other than any state that
derives from the parameters to that method of course.

Practically speaking, it's hard to imagine fixing this would break anything
out there. It seems more likely that it would accidentally fix something,
so to speak.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250429/81c96c6b/attachment.htm>