Files
docker-cli/components/engine/daemon
Doug Davis 85527e5274 Fix race condition on container stop
I'm fairly consistently seeing an error in
DockerSuite.TestContainerApiRestartNotimeoutParam:

docker_api_containers_test.go:969:
    c.Assert(status, check.Equals, http.StatusNoContent)
    ... obtained int = 500
    ... expected int = 204

And in the daemon logs I see:
INFO[0003] Container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971 failed to exit within 0 seconds of SIGTERM - using the force
ERRO[0003] Handler for POST /containers/{name:.*}/restart returned error: Cannot restart container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971: [2] Container does not exist: container destroyed

ERRO[0003] HTTP Error                                    err=Cannot restart container 8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971: [2] Container does not exist: container destroyed
 statusCode=500

Note the "container destroyed" error message.  This is being generatd by
the libcontainer code and bubbled up in container.Kill() as a result of the
call to `container.killPossiblyDeadProcess(9)` on line 439.

See the comment in the code, but what I think is going on is that because we
don't have any timeout on the Stop() call we immediate try to force things to
stop. And by the time we get into libcontainer code the process just finished
stopping due to the initial signal, so this secondary sig-9 fails due to the
container no longer running (ie. its 'destroyed').

Since we can't look for "container destroyed" to just ignore the error, because
some other driver might have different text, I opted to just ignore the error
and keep going - with the assumption that if it couldnt send a sig-9 to the
process then it MUST be because its already dead and not something else.

To reproduce this I just run:
curl -v -X POST http://127.0.0.1:2375/v1.19/containers/8cf77c20275586b36c5095613159cf73babf92ba42ed4a2954bd55dca6b08971/restart

a few times and then it fails with the HTTP 500.

Would like to hear some other ideas on to handle this since I'm not
thrilled with the proposed solution.

Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 29bdcaf3cfe0f4bfeed9f7f59ca8f6ad2f41dfd9
Component: engine
2015-05-25 04:28:23 -07:00
..
2015-04-07 08:43:14 -07:00
2015-05-20 08:51:27 -07:00
2015-05-18 16:50:14 +00:00
2015-04-30 12:17:33 -07:00
2015-05-19 22:40:19 +00:00
2015-05-16 12:38:20 -07:00
2015-05-14 15:57:45 -07:00
2015-05-06 16:19:27 -07:00
2015-04-13 15:27:45 +02:00
2015-04-09 16:06:54 -07:00
2014-05-17 17:56:02 +00:00
2015-04-10 01:52:55 +08:00
2015-04-16 18:50:24 +02:00
2015-04-23 10:23:02 +08:00
2015-04-16 10:56:15 -04:00
2015-04-12 00:41:16 +02:00
2015-04-09 18:17:50 -07:00

This directory contains code pertaining to running containers and storing images

Code pertaining to running containers:

  • execdriver
  • networkdriver

Code pertaining to storing images:

  • graphdriver