Perl as PID 1 under Docker
tech-blog.cv-library.co.uk
Perl as PID 1 under Docker
1–10 of 16 posts
Re: Perl as PID 1 under Docker
#2I 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.
Re: Perl as PID 1 under Docker
#3No 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.
Re: Perl as PID 1 under Docker
#4No 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 usu…
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.
Re: Perl as PID 1 under Docker
#5No 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 usu…
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.
Re: Perl as PID 1 under Docker
#6I 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.
Re: Perl as PID 1 under Docker
#7Noticed 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.
Re: Perl as PID 1 under Docker
#8I 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
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).
Re: Perl as PID 1 under Docker
#9I 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.
Re: Perl as PID 1 under Docker
#10Nice writeup. Interesting enough, SIGKILL does not work from inside the container: https://andrestc.com/post/killing-container-inside/.