-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Don't wait for signalled processes if subreaper is enabled #1677
Comments
Makes sense to me 👍 |
To be completely clear, there is no problem in this case with |
FYI We handle a global subreaper in containerd with the reaper package here: https://github.com/containerd/containerd/blob/master/reaper/reaper.go You do have to modify your code with exec.Cmd usage to use the reaper wait functions but it works out in the long run. If this helps your issues. |
@crosbymichael thanks for the link. I don't know if this can help since using this reaper code won't prevent this https://github.com/opencontainers/runc/blob/master/libcontainer/init_linux.go#L510 to be called. If something else (than my subreaper) reap the process, I have no way to tell what was the exit code of this process and I cannot send it back to the host as expected. |
When a subreaper is enabled, it might expect to reap a process and retrieve its exit code. That's the reason why this patch is giving the possibility to define the usage of a subreaper as a consumer of libcontainer. Relying on this information, libcontainer will not wait for signalled processes in case a subreaper has been set. Fixes opencontainers#1677 Signed-off-by: Sebastien Boeuf <[email protected]>
When a subreaper is enabled, it might expect to reap a process and retrieve its exit code. That's the reason why this patch is giving the possibility to define the usage of a subreaper as a consumer of libcontainer. Relying on this information, libcontainer will not wait for signalled processes in case a subreaper has been set. Fixes opencontainers#1677 Signed-off-by: Sebastien Boeuf <[email protected]>
When a subreaper is enabled, it might expect to reap a process and retrieve its exit code. That's the reason why this patch is giving the possibility to define the usage of a subreaper as a consumer of libcontainer. Relying on this information, libcontainer will not wait for signalled processes in case a subreaper has been set. Fixes opencontainers#1677 Signed-off-by: Sebastien Boeuf <[email protected]>
Makes sense to me too |
In case the consumer of libcontainer sets a subreaper, we should not wait for processes when signalling them (https://github.com/opencontainers/runc/blob/master/libcontainer/init_linux.go#L467-L517). Otherwise, we have a race about the reaping, and in case the reaping is done from this function, our subreaper will not reap the expected process, meaning that we're gonna miss the exit code related to this process.
The text was updated successfully, but these errors were encountered: