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.
this should not ignore all errors, but only the "not found" one
There was a problem hiding this comment.
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.
have you tried using errdefs.IsNotFound(err) ?
There was a problem hiding this comment.
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.
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.
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.
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