Re: system(3) semantics when SIGCHLD is SIG_IGN'd

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

> Date: Sat, 12 Aug 2023 22:48:05 -0400 (EDT)
> From: Mouse <mouse%Rodents-Montreal.ORG@localhost>
> 
> >     If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to
> >     SIG_IGN, [...]
> 
> Check my understanding: this applies to wait(2), but not alternatives
> like waitpid(2) or wait4(2), right?

If you read all the way to the end of the sentence I quoted, you'll
find your answer:

    [...] and the process has no unwaited for children that were
    transformed into zombie processes, the calling thread will block
    until all of the children of the process containing the calling
    thread terminate, and wait() and waitpid() will fail and set errno
    to [ECHILD].

    https://pubs.opengroup.org/onlinepubs/7908799/xsh/wait.html

Newer POSIX extends this to waitid(2).  wait3, wait4, and wait6 are
technically non-POSIX extensions and so could, in priciple, be used to
avoid this if there were a mechanism.

But there's no mechanism in the kernel for recording the information
when SIGCHLD is set to SIG_IGN because the information is destroyed
when the process exits and there's nowhere to store it -- that's what
a zombie process is for, and setting SIGCHLD to SIG_IGN/SA_NOCLDWAIT
asks the kernel not to leave zombie processes.  The kernel would need
to know that the parent wants a zombie for the the child spawned by
system(3) but not any other children.

> > So, should we do anything about this in system(3)?
> 
> > Cons:
> > [...]
> > - Changing signal actions has the side effect of clearing the signal
> >   queue, and I don't see a way around that.
> 
> But is changing the signal action the only way to make system(3)
> "work"?  I'm not convinced it is.

Open to other ideas!  But I'm leaning toward thinking we should just
leave it as is.  It looks like glibc doesn't do anything about this
either, for instance.