What the latest with the zombie process reaping problem?


This is a question about the zombie reaping problem and identifying the current ‘best’ approach for managing that risk when using docker daemons orchestrated via docker-compose.

My understanding is that it’s still possible for a process to become orphaned when using a Linux base image, the zombie reaping problem as described in https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/

From reading the docker documentation, it seems that Docker now contains support for invoking the Tini init process that performs the needed reaping, enabled when passing the --initoption to the docker run command. However this is an explicit option, implying the default does not apply this init process.

Then to create an image that is not exposed to the zombie reaping problem, two candidates parent images (or configuration to duplicate) to choose between are the phusion/baseimage and the Tini image (Tini is contained in docker and is the init process invoked when passing --init). (github /phusion/baseimage-docker , github /krallin/tini)

Does this train of though make sense, or have I missed something? (such as the Tini process running by default in Docker, so nobody need concern themselves with this problem)

Docker version, as requested by the forum posting guide….

> docker version
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:13:02 2018
 OS/Arch:      darwin/amd64
 Experimental: false
 Orchestrator: swarm

  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:22:38 2018
  OS/Arch:      linux/amd64
  Experimental: true
1 Like

Yes. That blog post is a pretty good description of the issue. If you control the application, and never launch a subprocess, it isn’t an issue; you can, with some care, reap zombies yourself as well.

True, but options like -p and -e are all but required for standard use too. I’d think documenting --init as a recommended startup option is a reasonable answer.

You can presumably install a lightweight init whatever other base image you’re using. The tini home page you linked has instructions on how to do it. The widely-used supervisord process manager, I’m guessing, will also pick up after unexpected child processes, though their documentation doesn’t seem to explicitly say that. BusyBox has an underdocumented init too which might do what you need.

Thanks reply, it’s much appreciated!

Yeah, this would be my preferred option, but sadly in this instance I don’t control the application.

Good point, I hadn’t considered documentation as a remedy, but it can be sound choice.

True, any lightweight init process would suffice, I’ll take a look at supervisord &BusyBox too.