Using waitExitOrRemoved for docker start
#25861
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
WeiZhang555
force-pushed
the
wait-remove-for-start
branch
6 times, most recently
from
18c9089
to
c9d18a6
Compare
| // no matter it's detached, removed on daemon side(--rm) or exit normally. | ||
| statusChan, err := waitExitOrRemoved(dockerCli, context.Background(), c.ID, c.HostConfig.AutoRemove) | ||
| if err != nil { | ||
| return fmt.Errorf("Error waiting container's exit code: %v", err) |
There was a problem hiding this comment.
We may want to store this error and return it later (instead of waiting on the status chan), or at least improve the error message since it's weird to say that you couldn't wait on a container's exit code before it's even started.
WeiZhang555
force-pushed
the
wait-remove-for-start
branch
from
c9d18a6
to
ae165ec
Compare
|
@cpuguy83 How about this one. |
| if err := dockerCli.Client().ContainerStart(ctx, c.ID, types.ContainerStartOptions{}); err != nil { | ||
| cancelFun() | ||
| <-cErr | ||
| if c.HostConfig.AutoRemove { | ||
| // wait container to be removed | ||
| <-statusChan |
There was a problem hiding this comment.
Do we need to check if statusErr != nil first?
There was a problem hiding this comment.
Correct. I will change it to
if c.HostConfig.AutoRemove && statusErr == nil { ... }
ae165ec
to
0559e70
Compare
|
@cpuguy83 updated as per your suggestion. PTAL. 😄 |
| return err | ||
|
|
||
| if statusErr != nil { | ||
| return fmt.Errorf("Can't get container's exit code: %v", statusErr) |
There was a problem hiding this comment.
Errors should start with lower case
|
One minor nit otherwise LGTM. |
Currently start command will invoke getExitCode - which is based on Inspect API - to get returned exit code after container exits. There's two race conditions here: if container is started with Restart Policy, there's chance that the container is restarted quickly before it calls getExitCode, under such circumstance, the exit code is wrong. if container is started with --rm, it's possible that container is removed before getExitCode, in this situation, you can't get correct exit code either. Replace getExitCode with waitExitOrRemoved can solve this problem. Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
WeiZhang555
force-pushed
the
wait-remove-for-start
branch
from
0559e70
to
b8464c1
Compare
|
@cpuguy83 fixed |
|
LGTM |
|
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently
startcommand will invokegetExitCode- which is based onInspectAPI - to get returned exit code after container exits, there'stwo race conditions here:
container is restarted quickly before it calls
getExitCode, under suchcircumstance, the exit code is wrong.
--rm, it's possible that container isremoved before
getExitCode, in this situation, you can't get correctexit code either.
Replace
getExitCodewithwaitExitOrRemovedcan solve this problem.Signed-off-by: Zhang Wei zhangwei555@huawei.com