Reputation: 1567
$ docker rm containername
containername
Then I tried to run a container and assigned it a name containername
docker run -it --rm -p 8080:8080 --name containername b014d35f03a
FATA[0000] Error response from daemon: Cannot start container 2dc7aa98e8213625352e0ef8aadeaa1b6b4a0ab92c6c64c4dafe870b5bb7a49e: Bind for 0.0.0.0:8080 failed: port is already allocated
Why is Docker now saying that containername
is taken? Shouldn't it have removed the container when it exits since I put in --rm
? And is there a way to fix this problem? (Always remove container when any exiting)
$ docker run -it --rm -p 8080:8080 --name containername b014d35f03a
FATA[0000] Error response from daemon: Conflict. The name "containername" is already in use by container 2dc7aa98e821. You have to delete (or rename) that container to be able to reuse that name.
Upvotes: 1
Views: 5197
Reputation: 311711
The first error, regarding the port being in use by another application, means that Docker failed to start the container:
FATA[0000] Error response from daemon: Cannot start container
2dc7aa98e8213625352e0ef8aadeaa1b6b4a0ab92c6c64c4dafe870b5bb7a49e:
Bind for 0.0.0.0:8080 failed: port is already allocated
Because it didn't start the container, the client never had the chance to start monitoring it in order to remove it on exit. I suspect the thinking behind this behavior is that you may want a chance to diagnose this sort of failure, rather than simply deleting the container outright.
You can:
Open an issue and/or submit code to change the behavior such that the container will be removed in any case, or
You can use an explicit docker rm
rather than relying on the client to do it for you. For example, you could always explicitly docker rm containername
before starting the container. This is a fairly common pattern, since it means that in the event of an error the container is still hanging around so you can diagnose it.
Upvotes: 2