When not to use docker run --init

Question

The --init flag of docker run causes the tini init system to be used as the ENTRYPOINT. As a consequence, the application running in the container will be a child process of the init system so that it can take care of signal handling, zombie reaping etc.

docker-compose also has an init: true service setting.

As tini works transparently, Dockerfiles don't need to be modified in any way (that's what that tini docs say).

So my questions are:

• Are there any downsides to using --init?
• Under which circumstances would it be better to avoid using --init?
• In case there are no serious downsides: Why is --init not the default setting?

Answer 1

There are no downsides of using the --init flag. However, tini the process that gets to be PID 1 in your container does not cover all functionalities of a init process. For most cases, this shouldn't be a problem as you just want SIGNALS handling and child processes handling.

Under which circumstances would it be better to avoid using --init?

If you coded your application to handle SIGNALS, for example in NodeJS:

const registerSignals = () => {
process.on('SIGTERM', () => {
    console.log('SIGTERM received');
    shutDown(0);
});
process.on('SIGINT', () => {
    console.log('SIGTERM received');
    shutDown(0);
});
}

AND if you have no zombie processes to reap OR your reaping zombie processes yourself

then you can avoid using --init or tini (Make sure to use exec form when starting your container if you want the above snippet to work)

In case there are no serious downsides: Why is --init not the default setting?

Because making your containers SIGNAL aware as my snippet shows is not so difficult and besides you might have some exotic case for PID 1 that tini does not cover so there is no good reason in injecting tini per default in all containers.

EDIT: Added Cameron's suggestion