wait for all children?

[bukzor]

We've encountered a couple third party systems (jenkins is one) that restart via (fork, die, self-exec).
This causes docker to stop since the run process is dead.
Dumb-init has the same behavior.

Would it be possible or a good idea to get dumb-init to help with this problem?

cc @dgholz

[bukzor]

To be clear, while I'm pretty sure this (waiting for all children to stop) shouldn't be the default behavior, possibly it would be a good optional behavior.

[bukzor]

Also: In this case and others, it's not possible to convince the service to re-exec rather than fork.

[chriskuehl]

Just to reiterate some of my comments from elsewhere: the current behavior is that dumb-init has a primary child, and when that primary child dies, all processes in the process group rooted at that child are sent SIGTERM when the child dies (in (the default) setsid mode, anyway) and then dumb-init exits. Out of setsid mode, dumb-init just exits. So either way your container will die. (And yes, I agree we wouldn't consider changing the default behavior, it's been very useful.)

dumb-init is in a position to handle this, but I think only in the case where it runs as PID 1, which is going to make testing a bit painful. When the child (the old Jenkins master) exits, its child (the new Jenkins master) will be orphaned and reparented under PID 1 (often dumb-init). But if it's not dumb-init, we won't be able to wait on it at all.

This was also sort of requested in #44. The best way I can think to implement this is along the lines of @vishvananda's suggestion:

Generally the practice is to wait on the pid of the child for the sigchild and then waitpid(-1) with WNOHANG for children to exit

It seems like we should be able to use all the existing code until we see the primary child exit, and then after that switch to a loop calling waitpid until we get ECHILD. (sigwait that we're using now will just block forever if there are no children left, as best as I can tell)

This seems pretty complicated, though (we still need to reap zombies during this time, for example). Can you see a better way?

I feel like we're probably going to find that we've traded one set of problems for another in many cases, though -- any leftover process could keep the container alive forever, when we often use dumb-init to avoid exactly that behavior in other systems.

[ibm-om]

That would be retaining the container state for process = jenkins when pattern of fork, die?

Buck Evan --- [Yelp/dumb-init] wait for all children? (#80) ---
From:"Buck Evan" notifications@github.comTo:"Yelp/dumb-init" dumb-init@noreply.github.comDate:Tue, May 24, 2016 17:40Subject:[Yelp/dumb-init] wait for all children? (#80)

We've encountered a couple third party systems (jenkins is one) that restart via (fork, die, self-exec). This causes docker to stop since the run process is dead. Dumb-init has the same behavior.
Would it be possible or a good idea to get dumb-init to help with this problem?
cc @dgholz
—You are receiving this because you are subscribed to this thread.Reply to this email directly or view it on GitHub

[chriskuehl]

Per my comment above, I don't really think we can do this without greatly complicating dumb-init. It seems like we'd have to make a special case for when we're PID 1.