-
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
Handling destroy of container #820
Conversation
Signed-off-by: rajasec <rajasec79@gmail.com>
Integration tests can be added in this case. |
Why is this a problem? I think it is reasonable that if a container goes to destroyed status, it should be cleaned up by |
@hqhq I was thinking from state perspective for the above scenario. Instead For this scenario |
This state handling should be solved via the create/start split now. I'll close this for now but let me know if you find any inconsistencies with the states in master. |
Clarify root path
Through c83b8c8 (Merge pull request opencontainers#820 from jhowardms\ ft/clarifyrootpath, 2017-05-18). Signed-off-by: W. Trevor King <wking@tremily.us>
Through f4d221c (Merge pull request opencontainers#880 from dqminh/wking-linux-only-capabilities-again, 2017-07-05). The rc6 release picked up an earlier version of these notes, and those entries are mostly unchanged except for: * The credentialSpec entry, which was opencontainers#814 for credentialspec and now also includes opencontainers#859 for credentialSpec. * The root(.path) Hyper-V entry, which was opencontainers#820 for root.path and now also includes opencontainers#838 for root. I also moved this into the "breaking changes" section, because rc5 Hyper-V configs required root to be set, and rc6 Hyper-V configs require it to not be set. Although whether rc5 allowed Hyper-V configs at all is not clear to me. * Fixed indenting for the typo-fixes entry, as well as a number of more recent typo-fix PRs. Signed-off-by: W. Trevor King <wking@tremily.us>
After killing the detached container, it goes back to destroyed state
When container is in destroyed state, if we start the container via exec, container started. After exiting the container, it goes back to destroyed state ( still retains the state.json).
Added the logic both start and exec to depend on container Processes interface for destroying the container rather than shouldDestroy variable.
Tested the following conditions
runc start test
runc exec test
exit the container
state.json is retained
state.json is cleared properly
runc start test -d
runc kill test SIGKILL
runc delete test
runc delete is not impacted by this change.
Signed-off-by: rajasec rajasec79@gmail.com