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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 19 May 2026 14:30:10 -0400
    From:        Christos Zoulas <christos%zoulas.com@localhost>
    Message-ID:  <645CF0B9-1ADB-4DFC-B5BC-E9844896BC1F%zoulas.com@localhost>


  | vfork() is temperamental.

Yes, I know.   Perhaps fortunately, at the minute, our shell doesn't
even really pretend to build outside NetBSD, so some of the issues aren't
relevant (something on my list to perhaps work on, if I ever find the time).

  | In some implementations the signal disposition is shared
  | between parent and the vforked() child.

Which is what I am dealing with at the minute ... if that isn't true of
NetBSD, then I have been (today) wasting some time - as I said, I can't
think of a good way to test this new issue (vfork() only problem).

What would help all of this, the issue Taylor found, and this variant
related problem, would be if sigaction() had a SA_RESETFORK flag, to
cause the signal in question to be reset to the default (SIG_DFL) in the
child after a fork() (including vfork()).   Want to add that?   All these
issues could be made to simply vanish if that existed.

kre