
Perl as PID 1 under Docker - diocles
http://tech-blog.cv-library.co.uk/2017/08/31/perl-as-pid-1-under-docker/
======
tomjakubowski
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.

[https://github.com/Yelp/dumb-init](https://github.com/Yelp/dumb-init)

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

~~~
clarkdave
Some container engines don't support the --init flag, such as Amazon ECS[0],
so there is still a place for dumb-init and tini for the time being.

[0] [https://github.com/aws/amazon-ecs-
agent/issues/852](https://github.com/aws/amazon-ecs-agent/issues/852)

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

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

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

------
andrestc
Nice writeup. Interesting enough, SIGKILL does not work from inside the
container: [https://andrestc.com/post/killing-container-
inside/](https://andrestc.com/post/killing-container-inside/).

------
alacombe
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:

# Run with care...

$ 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'

^C

[bash enter in infinite loop]

I'm asking because my Fedora 25 install does not include docker 1.13 yet.

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

[0] [https://docs.docker.com/engine/installation/linux/docker-
ce/...](https://docs.docker.com/engine/installation/linux/docker-ce/fedora/)

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

~~~
fapjacks
Yes, for some reason, loads of people expect containers to behave like virtual
machines.

