Misbehaving exit status from Hotspot
david.holmes at oracle.com
Sun Jul 1 12:16:14 UTC 2018
On 29/06/2018 7:50 PM, Florian Weimer wrote:
> On 06/29/2018 01:51 AM, David Holmes wrote:
>> To be clear, I think the libc advise on this topic is just wrong-headed:
>> "Such a handler should end by specifying the default action for the
>> signal that happened and then reraising it; this will cause the
>> program to terminate with that signal, as if it had not had a handler."
>> It's not even self-consistent because it states this for the
>> "termination signals" but when caught some of these signals
>> intentionally do not trigger termination. So following that advice for
>> SIGQUIT would be completely wrong for the JVM!
> The advice seems appropriate to me for handlers that lead to
> termination, as generally intended for these signals. SIGQUIT doesn't
> do that for the JVM, so the advice doesn't apply.
That's somewhat selective. The document claims these are all termination
signals and should be handled the same way.
> SIGTERM appears to do
> so. So why not preserve in the information that the process was shut
> down by SIGTERM by reraising the signal? This might confer useful
> information to the caller.
The information is already preserved in the exit code of the JVM when it
There's no justification for changing 20+ years of behaviour here - the
JVM is doing nothing wrong.
More information about the hotspot-runtime-dev