Perl as PID 1 under Docker | Hacker News Reader

Perl as PID 1 under Docker

tech-blog.cv-library.co.uk

71 pointsdiocles15 comments

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

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.

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

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

>"In the happy path with a single process ..."

What is meant by "the happy path"? I've seen this reference a couple of time now but have not found a clear explanation.

The path where everything goes right/as expected. No error or special handling is needed.

https://en.wikipedia.org/wiki/Happy_path

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.

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

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'

[bash enter in infinite loop]

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

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

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.

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

Reply on news.ycombinator.com