Docker and the PID 1 zombie reaping problem (2015) | Hacker News Reader

Docker and the PID 1 zombie reaping problem (2015)

blog.phusion.nl

20 pointsawongh11 comments

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.

Well, we have things like minit, you know. https://github.com/chazomaticus/minit

(2015)

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...

Previous discussion: https://news.ycombinator.com/item?id=8916785

Thanks for posting the back history on this. I was reading the website and the voice in my head was going "I think this was solved."

or... you could use LXC instead?

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

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.

> Docker isn't interested in solving the problem

Or Docker is creating the problem by doing it wrong.

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.

Reply on news.ycombinator.com