-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Fix #10661: docker compose up always kills the containers on second Ctrl-C #11718
Conversation
Kill executed on the second Ctrl-C of docker compose up was filtering containers depending on its state. In some cases the containers can reach an state for what these filters don't get any container, and the command keeps reporting `no container to kill`. Remove this filtering, so it tries to kill any container it finds, independently of its state. Fixes docker#10661 Signed-off-by: Jaime Soriano Pastor <[email protected]>
1a39a07
to
2e8b379
Compare
AFAICT
would need to ignore such an error, assuming this is the right fix for this race condition |
You are right, this was briefly showing an error. I have changed the code to use the internal kill method, that doesn't show the progress. And to ignore the returned error. |
Signed-off-by: Jaime Soriano Pastor <[email protected]>
bb43c4a
to
33bf583
Compare
pkg/compose/up.go
Outdated
return s.Kill(context.Background(), project.Name, api.KillOptions{ | ||
// Intentionally ignore errors, for cases where some | ||
// of the containers are already stopped. | ||
s.kill(context.Background(), project.Name, api.KillOptions{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this should not ignore all errors, but only the "not found" one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't find a reliable way to distinguish errors here, as they don't seem to be typed. Should I add the check based on the text of the error? I guess it would be to check if the error message contains is not running
.
Also, with the current code, even if it returns the error, it doesn't seem to be doing anything about it. If the kill fails, the loop is still finished and the command hangs if there are still containers running. I could try to fix this too if I add error handling.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
have you tried using errdefs.IsNotFound(err)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! This worked. I also checked errdefs.IsConflict
, which happens if one of the containers is already stopped.
Project: project, | ||
}) | ||
}) | ||
return nil |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am removing this return, so it is possible now to try to kill the containers again after one kill failed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not be necessary, I hardly can imagine process could survive a SIGKILL
Also I'm not sure about the potential side-effects doing so, so if you don't mind I'd prefer to be conservative here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, indeed hopefully no process is going to survive a SIGKILL 🙂 But this is sending requests to kill containers to the docker daemon through HTTP, so there are other things that could fail in the way.
In any case I agree with being conservative and keep previous behaviour, I will revert this.
Signed-off-by: Jaime Soriano Pastor <[email protected]>
f09eb66
to
e22fe02
Compare
Signed-off-by: Jaime Soriano Pastor <[email protected]>
What I did
Hitting Ctrl-C twice in docker compose up is supposed to immediately kill the containers.
Kill executed on the second Ctrl-C was filtering containers depending on its state. In some
cases the containers can reach an state for what these filters don't get any container, and
the command hangs while printing
no container to kill
.Remove this filtering, so it tries to kill any container it finds, independently of their state.
Related issue
Fixes #10661