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.<p><a href="https://github.com/Yelp/dumb-init" rel="nofollow">https://github.com/Yelp/dumb-init</a>
No mention of linux' pid_namespaces documentation ?<p>> 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.<p>> 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.
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.<p>Source: `docker pull jbergstroem/mariadb-alpine`<p>edit: docker should really open the doors for a cleanup/shutdown phase. There's both entrypoint and cmd but not a "exit" command.
Nice writeup. Interesting enough, SIGKILL does not work from inside the container: <a href="https://andrestc.com/post/killing-container-inside/" rel="nofollow">https://andrestc.com/post/killing-container-inside/</a>.
I wonder if using the --init flag would also fix the docker issue with bash scripts getting in an infinite loop when the script catch signals:<p># Run with care...<p>$ sudo docker run -it docker.io/ubuntu:14.04 /bin/bash -c 'trap x EXIT; x() { echo exit; }; while sleep 1; do echo sleep; done'<p>^C<p>[bash enter in infinite loop]<p>I'm asking because my Fedora 25 install does not include docker 1.13 yet.
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.