Re: [process] Process.Spawn leaves the child in zombie state on posix

From: Benedek Tass (tass.benedek_at_[hidden])
Date: 2022-07-08 07:59:52

The following figure may clarify the idea i propose:

PARENT  -->fork()----------------------------------waitpid()--->
              \                                        /
               \         signal(SIGCHLD,SIG_IGN)      /
CHILD          fork()----signal(SIGHUP,SIG_IGN)----exit()   # this process
takes the burden of ignoring SIGCHLD from parent
                 \              setsid()
                  \
GRANDCHILD       execve()------>

Benedek Tass <tass.benedek_at_[hidden]> ezt írta (időpont: 2022. júl. 7., Cs,
13:44):

> Have you checked out the sketch i provided? It seems to me that it solves
> the problem reasonably well.
>
> Klemens Morgenstern via Boost <boost_at_[hidden]> ezt írta (időpont:
> 2022. júl. 7., Cs, 13:22):
>
>> I don't think this is a solvable problem.
>> The reason is that you need to set SIGCHLD to SIGIGN for the whole
>> application in order to prevent zombies. Doesn't really work as a general
>> solution, which is why I'll deprecate that function at some point.
>>
>> You can probably `waitpid(-1, &status, 0); from time to time to reap the
>> zombie processes or you can put them in a process group; but I couldn't
>> come up with a satisfying solution, which is why the only way will be to
>> just hold a handle to the child process.
>>
>> On Thu, Jul 7, 2022 at 7:08 PM Benedek Tass via Boost <
>> boost_at_[hidden]>
>> wrote:
>>
>> > I was planning to send an example project, I'm sending it now as an
>> > attachment.
>> > As the demo sketch shows, I would absolutely call waitpid() in the
>> parent
>> > process, the sig_init_-like class' on_success() method would be a
>> > reasonable place for it. The current implementation doesn't lend itself
>> to
>> > an easy fix in case of this bug, I don't have a fully fletched idea how
>> to
>> > do it.
>> >
>> >
>> > Andrey Semashev via Boost <boost_at_[hidden]> ezt írta (időpont:
>> 2022.
>> > júl. 6., Sze, 17:28):
>> >
>> > > On 7/6/22 16:28, Benedek Tass via Boost wrote:
>> > > > Hi, everyone!
>> > > >
>> > > > This bug was observed in 2022.07.05, using boost version 1.79.0.
>> > > > Similar behaviour was commented on before on online messageboards.
>> > > >
>> > > >
>> > > > Bug description
>> > > >
>> > > > When starting a new, detached process with Process.Spawn in a posix
>> > > system,
>> > > > if the parent process outlives the child, the child process remains
>> in
>> > > > zombie state for the parent process' lifetime.
>> > > > The bug described above is demonstrated in the CMake project
>> attached
>> > to
>> > > > this document.
>> > > >
>> > > >
>> > > > Analysis
>> > > >
>> > > > The spawn function injects the syscall "signal(SIGCHLD, SIG_IGN)"
>> with
>> > a
>> > > > functor of type boost::process::detail::posix::sig_init_. This is
>> done
>> > to
>> > > > the forked child process, to no avail. And this is not done (and
>> should
>> > > not
>> > > > be done) in the parent process being too intrusive.
>> > > >
>> > > >
>> > > > Possible mitigation
>> > > >
>> > > > Introducing an in-between forked process that serves as the parent
>> of
>> > the
>> > > > to-be-spawned process with SIGCHLD set to SIG_IGN would prevent the
>> > > spawned
>> > > > process to become zombie, and simultaneously does not disturb the
>> > parent
>> > > > process' signal handlers.
>> > > > Introducing another class alternative to sig_init_ with the
>> > functionality
>> > > > described above would be a reasonable approach. An implementation
>> > sketch
>> > > of
>> > > > the double fork method can be found in the attached project.
>> > > >
>> > > >
>> > > > System used
>> > > >
>> > > > OS: Ubuntu 18.04.6 LTS
>> > > > arch: x86_64
>> > > > compiler: gcc-7.5.0
>> > > > libc: libc-2.27
>> > > > boost: 1.79.0 (built from source)
>> > >
>> > > You should probably report bugs on GitHub:
>> > >
>> > > https://github.com/boostorg/process/issues
>> > >
>> > > In the bug, it is always desirable to post a small compilable code
>> > > sample that reproduces the issue.
>> > >
>> > > Regarding the proposed fix, it's not clear how introducing an
>> > > intermediate process would fix the parent not calling waitpid() or
>> > > equivalent. You'd just get a different zombie process.
>> > >
>> > > _______________________________________________
>> > > Unsubscribe & other changes:
>> > > http://lists.boost.org/mailman/listinfo.cgi/boost
>> > >
>> >
>> > _______________________________________________
>> > Unsubscribe & other changes:
>> > http://lists.boost.org/mailman/listinfo.cgi/boost
>> >
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>