The actual reason you really need a proper PID 1 is not explained in this post, but a couple of clicks away at [0]:<p><pre><code> >[...] the init process must also wait for child processes to terminate,
>before terminating itself.
>If the init process terminates prematurely then all children are terminated uncleanly by the kernel.
</code></pre>
0: <a href="https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/" rel="nofollow">https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zomb...</a>
Very nice! I see this as the next evolution to the phusion's custom init system[0], which was created to solve largely the same problems.<p>I should be able to take Yelp's dumb-init and add it easily to any linux container I want -- including things such as Alpine[1]<p>[0] <a href="https://github.com/phusion/baseimage-docker/blob/master/image/bin/my_init" rel="nofollow">https://github.com/phusion/baseimage-docker/blob/master/imag...</a>
[1] <a href="https://github.com/gliderlabs/docker-alpine" rel="nofollow">https://github.com/gliderlabs/docker-alpine</a>
If I understand correctly, the main goal here can be summarized in the quote below:<p><i>"The motivation: modeling Docker containers as regular processes</i><p><i>[...] we want processes to behave just as if they weren’t running inside a container. That means handling user input, responding the same way to signals, and dying when we expect them to. In particular, when we signal the docker run command, we want that same signal to be received by the process inside."</i><p>and that seems to me as the core reason why they can't just use a simple init system (like e.g. runit I suppose?)
> Having a shell as PID 1 actually makes signaling your process almost impossible. Signals sent to the shell won’t be forwarded to the subprocess, and the shell won’t exit until your process does. The only way to kill your container is by sending it SIGKILL (or if your process happens to die).<p>Noob question. Why is it impossible? You have the PID, no?
This looks to be an alternative <a href="https://github.com/krallin/tini" rel="nofollow">https://github.com/krallin/tini</a>
Another alternative, for what it's worth: <a href="https://github.com/rciorba/pidunu" rel="nofollow">https://github.com/rciorba/pidunu</a><p>I've created an Ubuntu PPA packaging of it (<a href="https://launchpad.net/~danieldent/+archive/ubuntu/pidunu" rel="nofollow">https://launchpad.net/~danieldent/+archive/ubuntu/pidunu</a>) and you can see an example of it in use at: <a href="https://github.com/DanielDent/docker-powerdns" rel="nofollow">https://github.com/DanielDent/docker-powerdns</a><p>For situations involving multiple processes, there's also <a href="https://github.com/just-containers/s6-overlay" rel="nofollow">https://github.com/just-containers/s6-overlay</a><p>Example use: <a href="https://github.com/DanielDent/docker-nginx-ssl-proxy" rel="nofollow">https://github.com/DanielDent/docker-nginx-ssl-proxy</a> (automated Let's Encrypt SSL front-end)
If it's such a straightforward fix, why isn't it part of the docker core? I'd love to hear from the docker team why it's not a concern for them. Presumably if it was they'd have addressed it by now.<p>From my own experience with docker in production, I'm yet to see any of the described scenarios crop up. Has anyone else, or is this solving an extreme edge case?
Is there any reason you wouldn't run normal "non-dumb" init for this using<p><pre><code> CMD ["/sbin/init", "2"]
</code></pre>
and start your app using init.d scripts or supervidord as usual?<p>I feel like logrotate, cron, etc, are worth having inside container no?
Reminds me of RancherOS that also have Docker running as PID 1: <a href="https://github.com/rancher/os#how-this-works" rel="nofollow">https://github.com/rancher/os#how-this-works</a>