dumb-init VS tini

I think you are on the right track in thinking it’s a signal handling issue. You mentioned using some “bash scripts”, have you tried something like dumb-init?

At the other extreme, there's dumb-init - it implements the special pid-1 behaviors and acts as a wrapper around the one script you want to run. It's ideal for containers or virtual machines that don't need user logins or more than one service.

Oh, and another thing. Many containers launch their main process from a shell script. When this happens, the shell script receives the SIGTERM event, not the application. Your shell script MUST relay SIGTERM events back to the main process, and it doesn’t happen by default. You can use a shell script wrapper, like dumb-init (https://github.com/yelp/dumb-init), as your entry point if you need to use a shell script on container startup.

It's a plus because Gentoo fully supports the choice of Systemd or OpenRC. It also has minit, dumb-init, sysvinit, cinit in tree for the more adventurous. No one was calling the AUR bloat, the parent comment just mentions that Gentoo has an equivalent project, GURU.

, but I prefer to not have to make this assumption and use an init system instead.

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

> It has no init system.

Apologies that I can't link directly to the "--init" flag but docker actually does have an init, it's just (err, was?) compiled into the binary: https://docs.docker.com/engine/reference/commandline/run/#op...

My recollection is that it either adopted, or inspired, https://github.com/Yelp/dumb-init#readme which folks used to put into their Dockerfile as the init system back in the day

Folks (ahem, I'm looking at you, eks-anywhere[0]) who bundle systemd into a docker container are gravely misguided, and the ones which do so for the ability to launch sshd alongside the actual container's main process are truly, truly lost

0: https://github.com/aws/eks-anywhere/issues/838#issuecomment-...

You can use something like dumb-init which is designed to correctly handle signals

yes busybox httpd or civetweb is even smaller, both around 300kb.

for tini you mean https://github.com/krallin/tini? how large is your final docker image, why not just alpine in that case which is musl+busybox

Tini, a useful process manager for containerized apps

Ah gotcha. I believe it can be baked into images as well, per the entrypoint example in the readme: https://github.com/krallin/tini

Not sure how this will fare IRL in k8s as I haven’t much experience there. It’s still silly that this is the default behavior where you need something like Tini, but I digress.

To be fair, even for running a single process the pitfalls are real. I've been seeing Tini[1] a lot for these situations.

I just read in the README that Tini is included by Docker since 1.13 if using --init flag.

[1] https://github.com/krallin/tini

The default init process used is the first docker-init executable found in the system path of the Docker daemon process. This docker-init binary, included in the default installation, is backed by tini.

AFAIK It's for the init process to reparent zombie processes. See TINI

The second easiest (and most common when your entry point is a bash script) is to use a fake init tool like tini