Re: bin/60275 (sh(1): race condition in signal handling on background subshell fork)

[kre%NetBSD.org@localhost]

Synopsis: sh(1): race condition in signal handling on background subshell fork

State-Changed-From-To: analyzed->feedback
State-Changed-By: kre%NetBSD.org@localhost
State-Changed-When: Mon, 18 May 2026 17:11:59 +0000
State-Changed-Why:
I believe this is now really fixed.

Further, I now understand the signal processing in the child process
from the PR, and no, it is not any kind of bug in ktrace, and nor is
it an issue with the shell, and nor was it (directly) relevant to the
issue reported.

What that was was the shell (in the child process) resetting the trapped
signals (in increasing numeric order) back to their default setups.
As the test had (in the parent) "trap '...' ALRM EXIT HUP INT PIPE TERM"
it was resetting those, in numeric signal order HUP INT PIPE ALRM TERM,
to their default values, and in the trace you showed, had done just
HUP and INT when the parent sent the TERM signal - the child received
that, it had not yet reset SIGTERM to be SIG_DFL, but also knew it
could not run the trap action, that's for the parent only, so it simply
ignored the signal.   The first attempt at a fix for this, only handled
the case where the signal was received very early in the child processing,
before it had started clearing the traps at all.   That is what usually
happened in the test prog (when it had no sleep 0.01 in it) - but just
enabling ktrace might have adjusted the relative timings enough to have
made that difference.

If you can confirm this is fixed, please either close the PR (or let me
know and I will), or if you want pullups done for it, change its state
to needs-pullups (and say which versions you think this issue warrants
pullups for, for for -11, whether before 11.0 is needed, or if after is OK).