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

From: Benedek Tass (tass.benedek_at_[hidden])
Date: 2022-07-07 06:04:48

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
>