Re: SIGCHLD set to SIG_DFL on exec(3)

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

    Date:        Sat, 8 Feb 2020 16:47:42 +0100
    From:        Kamil Rytarowski <n54%gmx.com@localhost>
    Message-ID:  <ed017398-4b47-14ad-68b8-35d3edd3d4d5%gmx.com@localhost>

  | We are allowed to fix this in the kernel for everybody:

Indeed we are.   And if you want to change things that way, that's fine.

It turns out this one wasn't the actual problem in this instance, so
doing that would have made no difference...   The issue with was with
SIGCHLD blocked, and that one POSIX doesn't allow us to undo.

Certainly, as the extract you quoted from the standard says, exec()ing
a new process with "unusual" signals blocked can lead to weird behaviour,
as almost nothing races around unblocking (etc) signals as part of the
startup code.   It doesn't help that SIGCHLD is decidely weird (thanks
to Sys V) with its bizarre side effects.

It seems likely that our shell actually never had a problem (though would
have, had SIGCHLD been ignored) with this, as we don't actually use
SIGCHLD for anything at all.    Why some other (well, apparently all
other) ash derived shells do is not clear to me - though over the years
our internal sh wait(1) code has been rewritten quite frequently it seems.

I would however keep the new code that sets SIGCHLD to SIG_DFL, and
unblocks it (always, regardless of its state at entry) even if the
kernel were changed as you suggest above, as one day I'd like to make
the netbsd sh (like several other programs we have) exportable to others
to use, and we cannot control what their kernels do.

We did have (well, I introduced) a problem when the shell inherited children
from a previous executable to occupy the process, if that child completed
at the "wrong" time we would dump core.. (which was also an aspect of this
issue) - which was trivial to fix once the possibility even occurred to me.
It isn't something that happens often.

Finally note that it took a particularly bizarre piece of bash code to make
bash exec another shell (or for that matter, any other process) in this way,
and that it did is most likely a bug in it (ie: not intententional) and
will probably get fixed, this is a very rare problem, with a very simple
fix, which really affects almost nothing, so I wouldn't spend a lot of time
worrying about other possible solutions.

kre