Misbehaving exit status from Hotspot

Charles Oliver Nutter headius at headius.com
Sat Jun 30 04:41:34 UTC 2018

On 06/29/2018 01:51 AM, David Holmes wrote:
> "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."

Yes, this is really what set me down the path of wishing Hotspot would
do the same thing. This and the fact that CRuby does it, and I can't
fit into certain CRuby deployments because JRuby can't emulate the
signal results.

On Fri, Jun 29, 2018 at 4:50 AM, Florian Weimer <fweimer at redhat.com> wrote:
> 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.  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.

You've got my vote!

I think it's worth enumerating the pros and cons, eh?


* waitpid-related macros would now show termination due to a signal
rather than a normal exit.


* waitpid-related macros would now show termination due to a signal
rather than a normal exit.
* They'd also show the actual signal value in termsig rather than the 128+N.
* The actual command line exit could would remain unchanged.

So...taking this another step...

Currently, you can *only* rely on the command line exit code, because
the  watipid macros just say it was a normal exit, and the rest of
their values are nonsense. So anyone writing process-management stuff
for Hotspot subprocesses can only use the exit code (128+N) to detect
that the exit was due to TERM.

And if we changed it? Well, the above would continue to work exactly
as it does now, but folks expecting GNU-like TERM handling
(propagation to default handler) would suddenly start to work with

Obviously I'm in favor of this, so I'd like to understand what this
change would break. It seems like a net positive.

- Charlie

More information about the hotspot-runtime-dev mailing list