20

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?
Peter Thomassen
  • 1,671
  • 1
  • 16
  • 28

1 Answers1

6

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

Bobby Donchev
  • 335
  • 1
  • 5
  • 3
    1.) Which are the init system functionalities that tini doesn't cover? I could not find a spec of what should be supported. 2.) tini forwards signals to its children, so signal-aware applications should work (this is not a reason to avoid tini). 3.) There are a LOT of standard images that don't run properly without --init. For example, MariaDB's entrypoint script mishandles SIGTERM; in the context of docker-compose, that leads to MariaDB getting killed after a while. This type of problem would not occur if tini was the default (maybe plus a --no-init flag for special cases). – Peter Thomassen Jun 15 '19 at 13:04
  • 1
    When you run a container without -p or --net=host its basically useless. Nonetheless the default is to map no ports to the outside. Basically what I am saying is that having docker do too much is not a good solution. again I think in some cases you would want to have your own init process because tini is not something like systemd – Bobby Donchev Aug 01 '19 at 13:23
  • 1
    It seems to me this answer should mention that if you are handling signals yourself, then you don't need Tini if you have no zombie processes to reap and/or your are doing your own zombie reaping. I think that should be explained. – Cameron Dec 14 '20 at 11:15