Skip to content
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

Initial libcontainer fixes #1

Merged
merged 8 commits into from Feb 1, 2017

Conversation

stevenh
Copy link

@stevenh stevenh commented Feb 1, 2017

These are the initial fixes required for our internal integration of libcontainer.

The were cherry-picked from each branch which has an outstanding PR against opencontainers/runc.

stevenh and others added 8 commits February 1, 2017 12:02
Allow destroying of running containers as documented by BaseContainer.Destroy() which states:
"Destroys the container after killing all running processes."

Also:
* Fix documentation typo for restoredState.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
During the bootstap processing nsenter it spawns a temporary child which then exits after processing. This child is created with CLONE_PARENT so its init parents responsibility to reap.

Update execSetns to reap these temporary children avoiding zombies.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
If a relative pathed exe is used for InitArgs init will fail to run if Cwd is not set the original path.

Prevent failure of init to run by ensuring that exe in InitArgs is an absolute path.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
signalAllProcesses was making the assumption that the requested signal was SIGKILL, possibly due to the signal parameter being added at a later date, and hence it was safe to wait for all processes which is not the case.

BaseContainer.Signal(s os.Signal, all bool) exposes this functionality to consumers, so an arbitrary signal could be used which is not guaranteed to make the processes exit.

Correct the documentation for signalAllProcesses around the signal delivered and update it so that the wait is only performed on SIGKILL hence making it safe to process other signals without risk of blocking forever, while still maintaining compatibility to SIGKILL callers.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
Both Process.Kill() and Process.Wait() can return errors that don't impact the correct behaviour of terminate.

Instead of letting these get returned and logged, which causes confusion, silently ignore them.

Currently the test needs to be a string test as the errors are private to the runtime packages, so its our only option.

This can be seen if init fails during the setns.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
If the init process fails during StartInitialization() it returns the cause to the parent via the pipe.

This initial failure causes knock on failures in parent which are reported and the error from the init process is lost.

For the early portion of start() we now attempt to read the error from the init process, if one is found we report it in preference, as it provides more relevant information about the actual problem.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
When signaling children and the signal is SIGKILL wait for children
otherwise conditionally wait for children which are ready to report.

This reaps all children which exited due to the signal sent without
blocking indefinitely.

Also:
* Ignore ignore ECHILD, which means the child has already gone.

Signed-off-by: Steven Hartland <steven.hartland@multiplay.co.uk>
Fixes: opencontainers#1236
Fixes: opencontainers#1281

Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
@stevenh stevenh merged commit 3e7ab25 into Unity-Technologies:multiplay Feb 1, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants