-
Notifications
You must be signed in to change notification settings - Fork 345
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
wait for all children? #80
Comments
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. |
Also: In this case and others, it's not possible to convince the service to re-exec rather than fork. |
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:
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 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. |
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) --- 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. |
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. |
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
The text was updated successfully, but these errors were encountered: