Misbehaving exit status from Hotspot

[David Holmes]

On 30/06/2018 2:41 PM, Charles Oliver Nutter wrote:
> 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.

I'd be sympathetic to providing some kind of hook, as John alludes, that 
might allow you to provide this behaviour without disrupting anyone 
else. At present you can't chain or install a handler for SIGTERM so a 
new capability would need to be added. A simple VM flag does not suffice 
because the VM does not perform the shutdown and so does not know when 
it is safe to re-raise the SIGTERM.

> 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?
> 
> Con:
> 
> * waitpid-related macros would now show termination due to a signal
> rather than a normal exit.
> 
> Pro:
> 
> * 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.

No the exitstatus is not nonsense and encodes the reason why the JVM 
chose to terminate.

> 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 that is precisely what they should be using.


> 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
> Hotspot.

If you change it then you potentially break everyone using waitpid who 
will now see an abnormal termination and perform abnormal, rather than 
normal, termination actions. They might be one and the same to you, but 
that doesn't mean they are one and the same to everyone.

David
-----

> 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
>