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:
--init?--init?--init not the default setting?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