cleanup/fix integration-cli for overlay in overlay#12206
cleanup/fix integration-cli for overlay in overlay#12206cpuguy83 merged 1 commit intomoby:masterfrom
Conversation
|
changed https://jenkins.dockerproject.com/job/Docker%20Master%20(overlay%20on%20overlay)/290/console to build from my branch as proof |
|
dammit, worked on my machine, there is a more annoying problem from these "Dead" containers |
|
back to the drawing board |
|
oooo i know |
jessfraz
force-pushed
the
11966-fix-racy-tests-on-overlay
branch
from
52453c4 to
cb9b8db
Compare
There was a problem hiding this comment.
this is the test that was creating the "Dead" container, and this is the fix
Signed-off-by: Jessica Frazelle <[email protected]>
jessfraz
force-pushed
the
11966-fix-racy-tests-on-overlay
branch
from
cb9b8db to
255b844
Compare
There was a problem hiding this comment.
this is the test that was creating the "Dead" container, and this is the fix
There was a problem hiding this comment.
its gotta be something with creating the volume via vfs in overlay in overlay that makes the container need a SIGTERM and SIGKILL
There was a problem hiding this comment.
but -f is always doing a sigkill, and isn't deleteContainer doing this exact thing?
There was a problem hiding this comment.
it is the super intricate difference of doing a SIGTERM, then SIGKILL that is different and somehow saves the day
There was a problem hiding this comment.
oh, I know why!
Dead containers happen when rm failed, but when you rm -f them again it forcibly removes them from docker regardless if there is an issue.
So first time with rm -f it had an issue, is marked as dead. If you just rm (no -f) it won't remove if the issue isn't resolved. But when you rm -f again, it will remove from docker regardless of issues.
There was a problem hiding this comment.
-f calls container.Stop(3) which does the TERM & KILL after 3 seconds, deleteContainer does just a SIGKILL
There was a problem hiding this comment.
Yes, but what it is causing the 2nd one to work isn't the TERM vs KILL, it's that -f has tells Docker to actually remove a container that is in a dead state no matter what.
There was a problem hiding this comment.
oh damn you were better than me, and i went into the depths of the sigs :(
There was a problem hiding this comment.
but i am only calling rm -f once not twice
There was a problem hiding this comment.
deleteContainers does just a kill and rm
|
EDIT: it failed on something unrelated because of a dev device but fixed here https://jenkins.dockerproject.com/job/Docker%20Master%20(overlay%20on%20overlay)/294/console /me cannot catch a break |
There was a problem hiding this comment.
😎 ya kinda left over from debuigging but i like
|
LGTM |
1 similar comment
|
LGTM |
cleanup/fix integration-cli for overlay in overlay
4 participants
closes #11966