I was relieved to see the article mention dumb-init in its conclusion. It's very likely what you want if you're not booting your containers with a full init system, and the README has a thorough explanation of why and how dumb-init works.
Does docker's newer --init flag not fully replace dumb-init's use? Or is dumb-init now just so you don't need to remember to --init whenever you use the container? I find it really weird that --init is a run-time option rather than something specified in the Dockerfile and baked into the image.
Lately I've found myself using runit a lot in docker containers. In the happy path with a single process, you still gain because it does leave you a bunch of nice hooks when docker exec'ing to shutdown/restart your main process when your developing.
In the more common path, I rarely have containers which don't more easily share 1 or 2 tightly coupled support containers (and in general I prefer having `docker run` just work, rather then turn into an affair with docker compose).
No mention of linux' pid_namespaces documentation ?
> Only signals for which the "init" process has established a signal
handler can be sent to the "init" process by other members of the PID
namespace. This restriction applies even to privileged processes,
and prevents other members of the PID namespace from accidentally
killing the "init" process.
> Likewise, a process in an ancestor namespace can—subject to the usual
permission checks described in kill(2)—send signals to the "init"
process of a child PID namespace only if the "init" process has
established a handler for that signal.
Yep, I wrote a container system similar to docker (also in perl) and had to make sure I had signal handlers setup properly for PID 1 so that weird things didn't happen when it execs to another process or fails during that. Not too difficult to do, but if you're doing docker then dumb-init is probably the better option than adding some boiler plate to everything you're going to make.
OP here - thanks for that! This blog post represents my slow realisation that PID 1 is even more special than I thought, and the fairly common pattern of running applications without an init system is quite broken.
Ran into the same issue with the mysql docker container which ultimately bothered me into making my own. Started off experimenting with trapping signals (trap foo INT,..) similar to the article but found this nifty `--gdb` (nowadays `--debug-gdb`) flag to mysqld that enables more signal handling.
Source: `docker pull jbergstroem/mariadb-alpine`
edit: docker should really open the doors for a cleanup/shutdown phase. There's both entrypoint and cmd but not a "exit" command.
Why don't you use Docker's installation repos [0]? The current version of Community Edition is 17.07, which is a handful of releases past 1.13. As someone that works with a few different customers with different versions of Docker, I'd really recommend upgrading to the latest version.
Noticed the same thing when running a node.js application in docker a while ago. Adding a signal handler manually fixed it easily. It was just not expected to be necessary.
https://github.com/Yelp/dumb-init