On 11/21/20 2:32 PM, Andreas Schwab wrote:
On Nov 21 2020, Chet Ramey wrote:
but since the shell always ignores SIGTERM,
Even a non-interactive shell?
No, you're right, it's SIGQUIT the shell always ignores. It catches SIGTERM
if there is an EXIT trap so it can run the trap on EXIT before exiting.
I'd also try it with one of the bash-5.1 testing releases, since I did
some reworking of how the shell handles SIGTERM back in April.
5.1-rc3 has the same issue.
OK, I instrumented bash a little bit, and discovered that the second
child doesn't start running, or at least doesn't get to the point in the
subshell initialization where it resets the signal handlers, until after
the parent sends SIGTERM.
That means the trap handler is still set to catch SIGTERM by the time
the signal arrives. However, the child is not allowed to run the trap
handler; it's supposed to reset the dispositions to the default. This
is the race condition.
It's a dilemma. I could block SIGTERM (all trapped signals, really) until
the child resets the signal dispositions, but that seems like a long time
to keep signals blocked. I'll look at it some more after bash-5.1 is
released.