
Docker and the PID 1 zombie reaping problem (2015) - awongh
https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
======
to3m
If only there were some mechanism in Unix that could be used for transferring
data. If only that mechanism could somehow record which processes were using
the resources in question! Then child processes could be integrated with that
system somehow, such that their exit code (or other matters of interest) could
be transferred through this conduit. And when all users of the resource had
indicated they were no longer interested, the child process could be discarded
- or, if still running, not then become a zombie when it finishes.

The current situation is suboptimal, I claim. But it's true that with no
convenient standard abstraction for transferring data, we don't really have
any other conceivable option.

------
desiderantes
Well, we have things like minit, you know.
[https://github.com/chazomaticus/minit](https://github.com/chazomaticus/minit)

------
_mikz
(2015)

~~~
_mikz
A year later, there is dumb-init[1].

Released as statically linked binary, it is simple ADD + chmod +x to get
running simple init without any dependencies.

^1: [https://engineeringblog.yelp.com/2016/01/dumb-init-an-
init-f...](https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-
docker.html)

------
phantom_oracle
or... you could use LXC instead?

------
smegel
Maybe Docker stinks?

> lxc-execute command will run the specified command into the container via an
> intermediate process, lxc-init. This lxc-init after launching the specified
> command, will wait for its end and all other reparented processes. (to
> support daemons in the container). In other words, in the container, lxc-
> init has the pid 1 and the first process of the application has the pid 2.

[https://linuxcontainers.org/fr/lxc/manpages/man7/lxc.7.html](https://linuxcontainers.org/fr/lxc/manpages/man7/lxc.7.html)

~~~
xahrepap
Or maybe, more likely, Docker isn't interested in solving the problem. But it
doesn't mean docker stinks just because another similar tool decided to solve
this problem. And it doesn't take away from all the problems docker does
solve.

~~~
smegel
> Docker isn't interested in solving the problem

Or Docker is creating the problem by doing it wrong.

~~~
xahrepap
Ok. So they're doing this one thing wrong (or in other words, you don't like
it). However, every project has its pros and cons. Docker definitely has its
cons, but for my use cases the pros far outweigh the cons. In this particular
case, the work arounds are numerous and very easy to use.

