On 3/4/26 2:05 PM, Daniel Villeneuve wrote:
Thanks for looking into this.
SIGHUP could explain a different behavior for the reboot case, but I
still
don't see why the following SIGTERM that is sent from the TERM trap and
received (seen in the strace output) does not kill the shell right at
that
moment.
I don't see any sign of SIGTERM being blocked or ignored (from the
strace
output) at the point the shell receives the TERM signal, so how could
the
shell ignore it and continue with the exit trap?
I've just added a line to dump /proc/$$/status just before the re-kill,
and
here is what I get:
SigCgt: 0000000043817efb
The 7 here tells me that SIGTERM (15) is still being caught, despite
the "trap - EXIT TERM" statement.
By default, bash catches fatal signals, sets a flag (all you can really do in a signal handler), and calls a handler when it can if the flag is set. It uses the handler to clean up resources (removing FIFOs, etc.), runs the exit trap, then resets the signal disposition to SIG_DFL and resends the signal to itself. That is the default handler trap reverts to. It could be that the shell gets SIGHUP, starts to run the exit trap, gets SIGTERM, notes that it's already processing a fatal signal, and waits, but there is code to exit immediately when that happens.
Could that explain why TERM
seems ignored? But this is also the case (7xxx) in normal
"kill process-group" mode, so why the different behavior?
It depends. Do you have a specific reproducer that works outside of reboot?
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
