Repository navigation
Need documentation on new docker-compose feature "init" #3149
Description
The releases page on github mentions the "init" feature of docker-compose 1.13 but the docs are not up yet and I can't find any mention in blogs. When documenting please mention whether it works with swarm (docker stack deploy -c docker-compose.yml).
File: compose/compose-file/compose-versioning.md, CC @londoncalling
Activity
londoncalling commentedon May 16, 2017
@jamshid ,
--initis documented for Compose v.2.2 here, but the reason it is not documented in the Compose v.3 file reference is that--initdoes not yet work with docker stack deploy and swarm services.Closing this issue, as currently no updates to docs are needed. Feel free to use this thread for follow-up questions if needed, though. Hope this helps.
cc @shin-
batjko commentedon Oct 12, 2017
It also does not work without swarm.
If I just run docker-compose up, I get the "Unsupported config option" error for all my mentions of init.
And I'm using compose file version 3.1.
johnknl commentedon Nov 4, 2017
I now have to fall back to using manual docker run invocations when I need zombie reaping, which is, to put it mildly, a PITA.
thaJeztah commentedon Nov 4, 2017
it's being worked on, and will come in a future release.
As an alternative, set the
--initdaemon option (or{"init":true}in your daemon.json), to enable the option by default.Note that reaping child processes should already be handled by any proper process; if not, it may be worth looking into the process you're running in your container.
johnknl commentedon Nov 5, 2017
@thaJeztah : thanks for the daemon option tip, I will try that. In another setting I do not have access to the daemon settings / invocation though.
I agree in an ideal world processes would manage their children properly but the reality is a little less ideal.
thaJeztah commentedon Nov 6, 2017
Yes, unfortunately, there are still examples that don't behave well. If you know of specific cases where it is needed, and you don't control the image, the
--initoption is indeed good. Unfortunately, some people lead to believe it's needed in every container, resulting in full-fledged init systems (upstart, systemd) to be added to each container, which, well, isn't ideal 😅.A good approach for that (assuming you have control over the images you deploy), is to make sure that images that don't behave well have an init added; the
--initoption basically just mounts thetiniinit to the container, and sets it as entrypoint. While the--initoption is not yet supported for services, you can add the tini binary to your images (see theREADMEfor tini).If you want to track progress on having this feature added to
docker serviceanddocker stack deploy; The SwarmKit side of things was implemented in moby/swarmkit#2350, unfortunately had to be reverted in moby/swarmkit#2383, but re-implemented in moby/swarmkit#2386.That code didn't find its way yet into the daemon, but will probably get merged soon (through moby/moby#35326).
After that's done; an update to the API will be needed (in the https://github.com/moby/moby repository), and after that's implemented, an update to the CLI to use this API option (work in progress PR here: docker/cli#479), and a pull request to update the docker-compose specs, and parser in the CLI (Support in the Docker Compose 3.x format is being tracked through docker/cli#51).
So, yes, work is in progress, but it takes some time to get all the bits in place 😅
thaJeztah commentedon Jun 25, 2018
compose v3 support for
initin stacks was merged in docker/cli#1129FranklinYu commentedon Aug 27, 2018
@thaJeztah Not just some people, this even applies for the official Node.js image. Due to nodejs/docker-node#848 I have to either add
--initto all my Node.js containers (what you're against), or change entrypoint in all my Node.js Dockerfile (not DRY at all). No wonder users think that--initshould be default.k8-scalar commentedon Aug 31, 2018
@FranklinYu I think @thaJeztah meant that it is not good practice if people copy an entire service init system like upstart in their container images. Moreover, the --init option is only needed when container applications fork child processes but don't reap child processes. A common case is Jenkins and probably Node.js as well.
FranklinYu commentedon Aug 31, 2018
@k8-scalar In the Node.js case it is not about child processes, but Node.js doesn't handle
SIGINT. I know it's not good practice so I myself won't use--initeverywhere; I'm just pointing out why others use it (the "some people" from quote). I understand them because I know "copy an entire service init system like upstart in their container images" is still easier than finding out which one does not work without--init, especially when even some official guys don't care about it.docker-robott commentedon Mar 8, 2023
Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.
If you have found a problem that seems similar to this, please open a new issue.
/lifecycle locked