Race between container remove and start when cleaning up port mappings

[hmahmood]

There is a race between cleanupPortBindings() and another go routine running a container remove operation. Specifically, the GetContainer() call may not find the container that has already been removed, but was still in the cache when the containerByPort map was checked.

Result: container start fails for a new container that may have conflicting port mappings with the container that was removed. This condition persists for any new container that is trying to create the same port mapping, since the containerByPort still has the port binding in there.

Fix: UnmapPorts and cleanupPortBindings should be idempotent, i.e. they should ignore conditions where they find the container is missing in the cache, and assume that it has been removed by another go routine, and that port mappings have already been cleaned up.

[hmahmood]

@andrewtchin

[anchal-agrawal]

+1, running into this quite often on 0.8.

$ sudo docker -H 192.168.77.225:2376 --tls run -it -p 80:80 --name webserver nginx
...
^C
$ sudo docker -H 192.168.77.225:2376 --tls ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                      PORTS                       NAMES
6ef754197499        nginx               "nginx -g daemon off;"   4 weeks ago         Exited (0) 12 seconds ago   192.168.77.225:80->80/tcp   webserver
$ sudo docker -H 192.168.77.225:2376 --tls rm 6
6
$ sudo docker -H 192.168.77.225:2376 --tls ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
$ sudo docker -H 192.168.77.225:2376 --tls run -it -p 80:80 --name webserver nginx
docker: Error response from daemon: Unable to find container "6ef7541974990e2e422b726b4656ae0b15d66fd3e060001b499052948cee4b73" in the cache, unable to get power state.

container-logs.zip

[mhagen-vmware]

lgtm