Skip to content

Conversation

rhatdan
Copy link
Contributor

@rhatdan rhatdan commented Apr 14, 2015

Assuming that docker kill is trying to actually kill the container is a mistake. If the container is not running we should report it back to the caller as a error.

Docker-DCO-1.1-Signed-off-by: Regan McCooey rmccooey27@aol.com (github: rmccooey27)
Docker-DCO-1.1-Signed-off-by: Dan Walsh dwalsh@redhat.com (github: rhatdan)

@runcom
Copy link
Member

runcom commented Apr 14, 2015

I think is a dup #12085

@runcom
Copy link
Member

runcom commented Apr 14, 2015

Also #12085 (comment)

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 14, 2015

We currently are returning errors from kill, so I don't agree with this statement. We can steal the unit test code from the other patch.

docker kill --signal 30 MISSINGCONTAINER

Currently returns an error.

This change just adds

docker kill --signal 30 NOTRUNNINGCONTAINER

The other pull request returned error on SIGINT of a non running container, which I left as not an error,
since this is similar to what we do with docker stop, I believe, But by sending a non SIGINT SIGTERM to a container, the user would expect the signal to be handled by the container, and if the container is not running, should generate an error.

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 14, 2015

This fix is in response to a bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=1209537

@@ -203,7 +203,7 @@ func postContainersKill(eng *engine.Engine, version version.Version, w http.Resp
name := vars["name"]

// If we have a signal, look at it. Otherwise, do nothing
if sigStr := vars["signal"]; sigStr != "" {
if sigStr := r.Form.Get("signal"); sigStr != "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I don't understand how this change relates to the PR? It seems it should never have been fetched from vars, but then how does kill even works today, and why is there no test to catch this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a real bug becuase signal comes from the GET params and not any URL segment

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, when testing the fix, a patch came in that blew up our fix. So I included it in the pull request.

@jessfraz
Copy link
Contributor

LGTM

@duglin
Copy link
Contributor

duglin commented Apr 22, 2015

can we get some testcases for this?

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 23, 2015

Added a test.

@duglin
Copy link
Contributor

duglin commented Apr 23, 2015

@rhatdan I don't see the test, did you forget to "git add" it?

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 23, 2015

@duglin oops

@@ -26,6 +26,11 @@ func (s *DockerSuite) TestKillContainer(c *check.C) {
c.Fatalf("failed to kill container: %s, %v", out, err)
}

/* Container should be stopped, second kill should return an error */
if _, _, err = runCommandWithOutput(killCmd); err == nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will always error because you can't run the same cmd twice.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be better to create a new test where you:

  • create a container
  • stop it
  • try to kill it and then check for your new error message.
    I think its important to make sure that we run, and verify, that the code you added is hit.

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 23, 2015

Ok added a new function.


killCmd := exec.Command(dockerBinary, "kill", cleanedContainerID)
/* Container should be stopped, second kill should return an error */
if _, _, err = runCommandWithOutput(killCmd); err == nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you check to make sure your text is displayed? Otherwise we can't be sure we're hitting your code - it could have failed for some other reason by mistake.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you addressed this comment yet

@cpuguy83
Copy link
Member

Error: kill succeeded on a stopped container

@rhatdan
Copy link
Contributor Author

rhatdan commented Apr 23, 2015

Ok this is broken, because we are only returning error on kill signal not on kill -9. I have fixed the test.
But it does bring up a question, should we be returning an error if a user tries to kill -9 a dead container.

Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
@duglin
Copy link
Contributor

duglin commented May 7, 2015

@rhatdan any chance of you addressing #12371 (comment) ?

@rhatdan
Copy link
Contributor Author

rhatdan commented May 11, 2015

@duglin I think the current pull request fails on all kill signals.

@cpuguy83
Copy link
Member

ping @rhatdan any update here?

@rhatdan
Copy link
Contributor Author

rhatdan commented May 27, 2015

@cpuguy83 I think it is all set? I have it returning errors for both kinds of kills.

c.Fatalf("kill succeeded on a stopped container")
}

deleteContainer(cleanedContainerID)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No need for this delete here.

Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)

killCmd := exec.Command(dockerBinary, "kill", "-s", "30", cleanedContainerID)
_, _, err = runCommandWithOutput(killCmd)
c.Assert(err, check.Not(check.IsNil), check.Commentf("Kill succeeded on a stopped container"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this addresses the previous comment, you're not checking the output to make sure you get the new error message you're generating.

Docker-DCO-1.1-Signed-off-by: Dan Walsh <dwalsh@redhat.com> (github: rhatdan)
@rhatdan
Copy link
Contributor Author

rhatdan commented May 28, 2015

The failure looks unrelated to the pull request.

@thaJeztah
Copy link
Member

@rhatdan triggered a rebuild

ping @cpuguy83 @duglin PTAL

@rhatdan
Copy link
Contributor Author

rhatdan commented Jun 10, 2015

Any movement on this one? Seems like a fairly simple patch to merge.

@cpuguy83
Copy link
Member

LGTM

1 similar comment
@duglin
Copy link
Contributor

duglin commented Jun 10, 2015

LGTM

duglin added a commit that referenced this pull request Jun 10, 2015
docker kill should return error if container is not running.
@duglin duglin merged commit 46af724 into moby:master Jun 10, 2015
@rhatdan
Copy link
Contributor Author

rhatdan commented Jun 10, 2015

Thanks.

@runcom
Copy link
Member

runcom commented Jun 10, 2015

I just want to note that here #12085 (comment) we talked about breaking Kill api and I'm just wondering if we should version this change

@thaJeztah
Copy link
Member

Good point @runcom.

@LK4D4 wdyt (since you raised that concern)

@runcom
Copy link
Member

runcom commented Jun 10, 2015

And also with this change not only container kill changes its behavior but also delete (and stop iirc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants