<div dir="ltr"><div dir="ltr">On Tue, Apr 29, 2025 at 9:55 AM Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com">thomas.stuefe@gmail.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>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.</div><div>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.</div><div><br></div><div>This seems a bit arbitrary to me and seems to support the view that this behavior is not intended.</div></div></div></blockquote><div><br></div><div>Agreed - water appearing randomly in the bottom of your boat is usually evidence of a leak somewhere :)</div><div><br></div><div>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.</div></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">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.</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">-Archie</div><div class="gmail_quote gmail_quote_container"><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>