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

From: Benedek Tass (tass.benedek_at_[hidden])
Date: 2022-07-07 11:44:41

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
>