Handling of USR2 signal in JVM on Linux

[David Lloyd]

On Thu, Jun 16, 2022 at 8:17 AM David Holmes <david.holmes at oracle.com> wrote:
> On 16/06/2022 12:09 am, Thomas Stüfe wrote:
> > On Wed 15. Jun 2022 at 15:06, David Holmes <david.holmes at oracle.com
> > <mailto:david.holmes at oracle.com>> wrote:
> >     Nor do I. SIGUSR2 is reserved for use by the VM and we document
> >     that. If
> >     you start throwing around random signals at processes then they can
> >     crash - so don't do that. I'm not sure ignoring signals that shouldn't
> >     be raised actually aids the end-user who obviously has an issue in
> >     their
> >     environment that needs to be addressed.
> >
> >
> > I see your point. I dislike crashes, especially ones they can be
> > reliably triggered from outside. You never can be sure about the
> > security implications either.
> >
> > If you dislike ignoring the signal, and since the default action for
> > SIGUSR1+2 is process termination, why not exit the VM with an error
> > message instead? At least we don’t have what looks like a random
> > segfault, and we could print out the sender pid  too.
>
> We could ... but then do we do that for every other signal that can be
> thrown at the JVM from externally and which will leads to crashes? Where
> do you stop?

Well, playing devil's advocate, why not? Would it be more complex than adding a

    if (si.si_pid != my_cached_pid) {
        // it came from Outside, let's exit with 128+signum
        // ...
    }

to the top of the signal handler(s)?

-- 
- DML • he/him