Hi, On Tue, Jun 07, 2016 at 12:44:20AM -0400, Selva Nair wrote: > This allows exit notification to complete and finally trigger SIGTERM. > The current practice of allowing a restart in this state clears > the exit notification timer data and thus loses the SIGTERM.
This is along the lines I was thinking as well, so I like it better than
the first try (which was sort of fiddling with the symptoms, but not with
the underlying signal handling problem).
What if SIGTERM+SIGUSR1 are received in very quick succession, so that
we haven't even entered "explicit_exit_notification_interval" yet?
I'm not sure if I understand the full chain of events that happen on
a (soft or hard) SIGTERM, what state ->signal_received has when the
exit notification timer is active, and under which circumstances
get_signal() is called to collect signal info into the context... this
is magic stuff...
My original idea was "the place that sets signal_received will not do
that for SIGUSR1 if a SIGTERM has already been received" (so, de-coupled
from the exit notification timer), but it seems that this is not easy
to do. So maybe your patch is the pragmatic way to solve this.
Arne?
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
signature.asc
Description: PGP signature
