The name "/data-container-name" is already used by container <hash>. You have to remove (or rename) that container to be able to reuse that name. #23371
Comments
|
how did you clean those containers ? Any exceptions happen why you clean those resources(include volume network etc.)? |
|
I have a helper function to nuke everything so that our Continuous blah, cycle can be tested, erm... continuously. Basically it boils down to the following: To clear containers:
To clear images:
To clear volumes:
To clear networks:
|
|
I have a swarm cluster where containers are being brought up and down a lot for ci purposes and I have the same problem. In my case I don't need to restart the machine though, usually killing all containers with then restarting docker and then recreating the swarm fixes it. |
|
Here's the log of a typical failure. I use ansible to run docker compose commands on one of the swarm nodes against the swarm. I've tried removing the container called "bookingeng811_redis1_1" manually but it doesn't exist anywhere. |
|
Have the same problem there. I frequently repeat the cycle :
At some point (2 - 3 days) it stops working: When I try to remove the container %container_id% manually it says: The container %container_id% not in the list docker ps -a and not in the folder /var/lib/docker/containers Maybe the root of the problem is removing container with -f parameter? so docker doesn't clean up correctly and docker daemon thinks that the container is still there. Docker version output:
Docker info output:
|
thaJeztah
added
the
kind/bug
|
Docker use 'nameIndex' to save the reference to containers. From the description, it seems that the issue is because We may be able to cleanup the out-of-sync nameIndex to temporarily address the issue. Though docker use several indices (e.g., linkIndex) in addition to the |
|
Is there any way to clean up out-of sync nameIndexes? |
|
For me what works is to stop docker daemon, remove everything from |
|
I am seeing same behaviour on 1.10.3 |
|
We are seeing this problem every day on CoreOS and Docker 1.10.3: in 50% of all cases, restarting docker daemon fixes the issue. In the other cases, we have to rm -rf /var/lib/docker. Both workarounds are disruptive to the production workload. |
|
@cdwertmann If you have to |
|
@cpuguy83 Here's what's inside the container directory: In config.v2.json I can see After manually deleting |
|
Seeing the same here: And this is how I start/stop/restart my containers: I got the same error, and then, nothing under |
|
This workaround for docker/compose#3277 (comment) also fix this issue... |
|
@marcelmfs not for me. I have to delete the entire |
|
Weird, for me it just worked. I'll try one more time to be sure. |
|
@marcelmfs so you just deleted docker/network/files/local-kv.db? |
|
Not only that, also removed all running containers |
|
I have not seen this issue since upgrading to docker 1.12 |
|
Is anybody else still seeing this with 1.12.x? |
|
I still need to upgrade to check... I'll allocate a window for upgrade tomorrow. |
|
This issue just popped up for me before updating to the latest (1.12.3), I uninstalled docker and reinstalled, and am unfortunately still seeing it. Output of Output of My workflow is a bit different than what has been mentioned in this thread, but it is similar in that I am doing lots of setup and teardown of containers in my testing suite. It might also be of interest that this is being done through requests to the Remote API. I'm a bit at a loss as to how to proceed. If requested, I can certainly prepare a test case of my issue, but as of now it is part of a larger project at work so I'll need to cut things down. Do y'all have any suggestions? |
|
@davidglivar You restarted the daemon and are still seeing the error? |
|
@cpuguy83 if by restarting the daemon, you mean stopping/starting the docker for windows app, yes. I have also reinstalled docker, as well as doing a 'factory' reset. I have not touched Hyper-V as I am not confident in its inner workings. |
|
@davidglivar So you are seeing this:
? |
|
@cpuguy83 yep! I just went through that sequence a couple of times to be sure. |
|
@davidglivar Can you |
|
@cpuguy83 |
|
Just to follow up on the previous day's comments: I still encountered the 409 error in the context of my application; however, a test script (here) has yet to display any problem. |
|
I created a reliable way of reproducing this. You can use the following python script to make any container name conflict: # pip install docker-py
from docker import Client
NAME = 'foobar'
cli = Client(version='auto')
# Create an invalid security option that will cause an error in
# https://github.com/docker/docker/blob/v1.10.3/daemon/create.go#L82
host_config = cli.create_host_config(security_opt=['invalid_opt'])
# After this, NAME will always conflict until the daemon gets restarted
try:
cli.create_container(name=NAME, host_config=host_config, image='', command='/')
except:
passThis problem can also be triggered in one of the following conditions which explain some of the cases where wiping of
The fix is to update to docker >=1.12.0 |
|
Sorry for a late come back on this issue. So far, since removing the workaround, our CI server did not suffer from this problem any longer. |
|
Also experiencing this with: There's no folder with the specified hash under |
|
@orodbhen If restarting the daemon didn't work, there there must be a container loaded with that name. |
|
@cpuguy83 No, there's no container with that name. I actually think this may be an issue with It happens when calling Strange, though, because it seems to be printing the error message produced by the daemon. @petrosagg do you have the same problem using the the docker shell command instead of docker-py? |
|
@orodbhen Are you sure your docker-py instance is talking to the same daemon as the CLI? |
|
There's only one daemon running: Both using I've created an issue for docker-py. But I'm not convinced yet that there's not some underlying issue with docker causing the problem. |
|
@orodbhen When you restart the daemon, can you grab the logs from the loading sequence (specifically loading containers)? This can't be a ref-counting issue if you've restarted the daemon. The name registrar is held only in memory and is rebuilt on daemon restart. |
|
Sorry, please disregard. It was a problem with the way I was logging errors that made it seem like the error was reoccurring. |
|
@orodbhen I'm not using docker-py, I only used it to create a small reproducible testcase. The reason it doesn't happen with the docker CLI is because the client sanitises the input before passing it to the server, but I wanted to have direct access to the server and cause the critical section to fail. |
`cleanupContainer` can fail to delete a container name from nameIndex if for example `container.ToDiskLocking()` fails. This is a problem because users of this function rely on it always cleaning up to ensure the in-memory data structures are consistent. One user is Daemon.newContainer() which first updates the nameIndex, and then registers the container, calling `cleanupContainer` whenever anything fails inbetween. Partial solution for moby#23371 Upstream-Status: Submitted [moby#27956] Signed-off-by: Petros Angelatos <petrosagg@gmail.com>
|
delete the service running in background. |
|
removed, reposted on #3277 |
|
I was also facing same issue with following errors: I just ran the command : sudo service docker restart And everything is working fine now. |
|
I was also facing this issue with the following errors: It turns out the directory where the compose file is located got renamed from the time the existing container was run and when I tried to rerun the container. I checked by running the following: I noticed project label was set to We have many containers running so restarting docker was not an optimal solution. |
|
|
A renomeação do container foi feita deletando seu nome antigo, com docker rm -f $(docker ps -a -q) ref: moby/moby#23371
|
I had to force remove the container |
and others
Output of
docker version:Output of
docker info:Additional environment details (AWS, VirtualBox, physical, etc.):
Private cloud with VMWARE hypervisor, running CentOS7.
Steps to reproduce the issue:
Describe the results you received:
Describe the results you expected:
Expect the cleaning process to clean everything and not receive:
Additional information you deem important (e.g. issue happens only occasionally):
Issue is happening frequently, every week or depending on the number of changes and integrations, even twice a week.
Cleaning the context again doesn't solve the problem, not even restarting docker, the only solution is the stop docker, remove all contents of
/var/lib/docker/*(/mnt/docker-data in my case), and start docker.The text was updated successfully, but these errors were encountered: