Moby: O nome "/ data-container-name" já é usado pelo container<hash>. Você tem que remover (ou renomear) esse container para poder reutilizar aquele nome.</hash>

como você limpou esses recipientes? Alguma exceção acontece porque você limpa esses recursos (inclui rede de volume, etc.)?

Eu tenho uma função auxiliar para destruir tudo de modo que nosso Blá, ciclo contínuo possa ser testado, erm ... continuamente. Basicamente, tudo se resume ao seguinte:

Para limpar os recipientes:

docker rm -f $(docker ps -a -q)

Para limpar imagens:

docker rmi -f $(docker images -a -q)

Para limpar volumes:

docker volume rm $(docker volume ls -q)

Para limpar redes:

docker network rm $(docker network ls | tail -n+2 | awk '{if($2 !~ /bridge|none|host/){ print $1 }}')

Eu tenho um cluster de enxame em que os contêineres estão sendo ativados e desativados muito para fins de ci e tenho o mesmo problema. No meu caso, não preciso reiniciar a máquina, geralmente matando todos os contêineres com

$ docker rm -f $(docker ps -a -q)

em seguida, reiniciando o docker

$ sudo service docker restart

e então recriar o enxame o corrige.

Aqui está o registro de uma falha típica. Eu uso o ansible para executar comandos docker compose em um dos nós do enxame contra o enxame.

TASK: [Run docker-compose up] ************************************************* 
failed: [XX.XX.XX.XX] => {"changed": true, "cmd": ["/usr/local/bin/docker-compose", "-f", "/containers/docker-compose/docker-compose-booking-pre-eng-811.yml", "--project-name", "booking-eng-811", "--verbose", "up", "-d"], "delta": "0:00:00.355991", "end": "2016-06-15 12:02:11.623256", "rc": 255, "start": "2016-06-15 12:02:11.267265", "warnings": []}
stderr: compose.config.config.find: Using configuration files: /containers/docker-compose/docker-compose-booking-pre-eng-811.yml
docker.auth.auth.load_config: Found 'auths' section
docker.auth.auth.parse_auth: Found entry (registry=u'my-private-registry', username=u'redacted-username')
compose.cli.command.get_client: docker-compose version 1.7.1, build 0a9ab35
docker-py version: 1.8.1
CPython version: 2.7.9
OpenSSL version: OpenSSL 1.0.1e 11 Feb 2013
compose.cli.command.get_client: Docker base_url: http://127.0.0.1:4000
compose.cli.command.get_client: Docker version: KernelVersion=3.10.0-327.18.2.el7.x86_64, Os=linux, BuildTime=Fri May 27 17:25:03 UTC 2016, ApiVersion=1.22, Version=swarm/1.2.3, GitCommit=eaa53c7, Arch=amd64, GoVersion=go1.5.4
compose.cli.verbose_proxy.proxy_callable: docker inspect_network <- ('back')
compose.cli.verbose_proxy.proxy_callable: docker inspect_network -> {u'Containers': {u'0f4c1b89e2ae9476a53f07552f678d2914bb391d1d80ab051f74925eb9fbf65a': {u'EndpointID': u'5f07ba0940ffcb4b0c2f0acf5424b6976b28bd8344a56b0464ab6517da884bc8',
                                                                                       u'IPv4Address': u'10.0.0.3/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:03',
                                                                                       u'Name': u'registrator_registrator_1'},
                 u'782c1d07d51f6871400da38e8840e81e9300f54a195b9e6ff2e931b23274655a': {u'EndpointID': u'c8654b5b73eaca7f630d6e2c4c898122a3ae6a86bd0cfab68a8654414fe4821a',
                                                                                       u'IPv4Address': u'10.0.0.2/24',
                                                                                       u'IPv6Address': u'',
                                                                                       u'MacAddress': u'02:42:0a:00:00:02',
                                                                                       u'Name': u'stdb1'},
...
compose.network.ensure: Network back declared as external. No new network will be created.
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=False, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/web:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/api-locations:master')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u"Emmet O'Grady",
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('my-private-registry/booking:eng-811')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'ArgsEscaped': True,
             u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'/bin/sh', u'-c', u'/entrypoint.sh'],
             u'Domainname': u'',
             u'Entrypoint': None,
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: web has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=web', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: api_locations has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=api_locations', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.project._get_convergence_plans: booking has upstream changes (redis1)
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=booking', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.parallel.feed_queue: Pending: set([<Service: web>, <Service: redis1>, <Service: api_locations>, <Service: booking>])
compose.parallel.feed_queue: Starting producer thread for <Service: redis1>
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.cli.verbose_proxy.proxy_callable: docker containers <- (all=True, filters={u'label': [u'com.docker.compose.project=bookingeng811', u'com.docker.compose.service=redis1', u'com.docker.compose.oneoff=False']})
compose.cli.verbose_proxy.proxy_callable: docker containers -> (list with 0 items)
compose.cli.verbose_proxy.proxy_callable: docker inspect_image <- ('redis:2.8.21')
compose.cli.verbose_proxy.proxy_callable: docker inspect_image -> {u'Architecture': u'amd64',
 u'Author': u'',
 u'Comment': u'',
 u'Config': {u'AttachStderr': False,
             u'AttachStdin': False,
             u'AttachStdout': False,
             u'Cmd': [u'redis-server'],
             u'Domainname': u'',
             u'Entrypoint': [u'/entrypoint.sh'],
             u'Env': [u'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin',
...
compose.service.build_container_labels: Added config hash: ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3
compose.cli.verbose_proxy.proxy_callable: docker create_host_config <- (memswap_limit=None, links=[], devices=None, pid_mode=None, log_config={'Type': u'', 'Config': {}}, cpu_quota=None, read_only=None, dns=None, volumes_from=[], port_bindings={}, security_opt=None, extra_hosts=None, cgroup_parent=None, network_mode='back', shm_size=None, tmpfs=None, cap_add=None, restart_policy={u'MaximumRetryCount': 0, u'Name': u'always'}, dns_search=None, privileged=False, binds=[], ipc_mode=None, mem_limit='64M', cap_drop=None, ulimits=None)
compose.cli.verbose_proxy.proxy_callable: docker create_host_config -> {'Binds': [],
 'Links': [],
 'LogConfig': {'Config': {}, 'Type': u''},
 'Memory': 67108864L,
 'NetworkMode': 'back',
 'PortBindings': {},
 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'},
 'VolumesFrom': []}
compose.service.create_container: Creating bookingeng811_redis1_1
compose.cli.verbose_proxy.proxy_callable: docker create_container <- (name=u'bookingeng811_redis1_1', image='redis:2.8.21', labels={u'com.docker.compose.service': u'redis1', u'com.docker.compose.project': u'bookingeng811', u'com.docker.compose.config-hash': 'ae3be0880fdcb78073a419c6102617b730bfb42171c8204bf51e5c36eb8a85f3', u'com.docker.compose.version': u'1.7.1', u'com.docker.compose.oneoff': u'False', u'com.docker.compose.container-number': '1'}, host_config={'NetworkMode': 'back', 'Links': [], 'PortBindings': {}, 'Binds': [], 'RestartPolicy': {u'MaximumRetryCount': 0, u'Name': u'always'}, 'Memory': 67108864L, 'LogConfig': {'Type': u'', 'Config': {}}, 'VolumesFrom': []}, environment=[], volumes={}, detach=True, networking_config={u'EndpointsConfig': {'back': {u'IPAMConfig': {}, u'Aliases': ['redis1']}}})
compose.parallel.parallel_execute_iter: Failed: <Service: redis1>
compose.parallel.feed_queue: Pending: set([<Service: booking>, <Service: api_locations>, <Service: web>])
compose.parallel.feed_queue: <Service: booking> has upstream errors - not processing
compose.parallel.feed_queue: <Service: api_locations> has upstream errors - not processing
compose.parallel.feed_queue: <Service: web> has upstream errors - not processing
compose.parallel.parallel_execute_iter: Failed: <Service: booking>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: api_locations>
compose.parallel.feed_queue: Pending: set([])
compose.parallel.parallel_execute_iter: Failed: <Service: web>
compose.parallel.feed_queue: Pending: set([])

ERROR: for redis1  Error response from daemon: Conflict. The name "/bookingeng811_redis1_1" is already in use by container 5ecf77fc7bbad0548cf34c891ac4d043b2692816b63ed97744924bc1296b8e65. You have to remove (or rename) that container to be able to reuse that name.
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "compose/cli/main.py", line 63, in main
AttributeError: 'ProjectError' object has no attribute 'msg'
docker-compose returned -1

Tentei remover o contêiner chamado "bookingeng811_redis1_1" manualmente, mas ele não existe em lugar nenhum.

Tenho o mesmo problema aí.

Eu freqüentemente repito o ciclo:

• docker stop% name%
• docker rm -f% name%
• docker pull% name%
• docker run% name%

Em algum ponto (2 a 3 dias) ele para de funcionar:
docker: Resposta de erro do daemon: Conflito. O nome "% name%" já está em uso pelo container% container_id% . Você precisa remover (ou renomear) esse contêiner para poder reutilizar esse nome.

Quando tento remover o contêiner% container_id% manualmente, ele diz:
Falha ao remover o contêiner (% container_id%): Resposta de erro do daemon: Nenhum contêiner:% container_id%

O contêiner% container_id% não está na lista docker ps -a e não está na pasta / var / lib / docker / containers

Talvez a raiz do problema seja remover o contêiner com o parâmetro -f? portanto, o docker não limpa corretamente e o daemon do docker pensa que o contêiner ainda está lá.

Saída da versão do Docker:

Cliente:
Versão: 1.10.3
Versão API: 1.22
Versão Go: go1.5.3
Git commit: 8acee1b
Construído:
OS / Arch: linux / amd64

Servidor:
Versão: 1.10.3
Versão API: 1.22
Versão Go: go1.5.3
Git commit: 8acee1b
Construído:
OS / Arch: linux / amd64

Saída de informações do Docker:

Recipientes: 27
Em execução: 13
Pausado: 0
Parado: 14
Imagens: 1512
Versão do servidor: 1.10.3
Driver de armazenamento: devicemapper
Nome da piscina: docker-8: 9-521647-pool
Tamanho do bloco da piscina: 65,54 kB
Tamanho do dispositivo básico: 107,4 GB
Sistema de arquivos de backup: xfs
Arquivo de dados: / dev / loop2
Arquivo de metadados: / dev / loop3
Espaço de dados usado: 53,62 GB
Total de espaço de dados: 107,4 GB
Espaço de dados disponível: 53,76 GB
Espaço de metadados usado: 129,9 MB
Total de espaço de metadados: 2,147 GB
Espaço de metadados disponível: 2.018 GB
Udev Sync Supported: true
Remoção adiada ativada: falso
Exclusão adiada ativada: falso
Contagem de dispositivos excluídos adiados: 0
Arquivo de loop de dados: / var / lib / docker / devicemapper / devicemapper / data
AVISO: O uso de dispositivos de loopback é fortemente desencorajado para uso em produção. Use --storage-opt dm.thinpooldev ou use --storage-opt dm.no_warn_on_loop_devices=true para suprimir este aviso.
Arquivo de loop de metadados: / var / lib / docker / devicemapper / devicemapper / metadata
Versão da biblioteca: 1.02.93 (30/01/2015)
Driver de execução: nativo-0.2
Driver de registro: arquivo json
Plugins:
Volume: local
Rede: ponte de host nula
Versão do kernel: 4.5.0-coreos-r1
Sistema operacional: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Arquitetura: x86_64
CPUs: 8
Memória total: 11,74 GiB
Nome: xx-escravo
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

O Docker usa 'nameIndex' para salvar a referência aos contêineres. Pela descrição, parece que o problema é porque nameIndex está fora de sincronia com os contêineres removidos. É aí que o erro é retornado.

Podemos limpar o nameIndex fora de sincronia para resolver temporariamente o problema. Embora o docker use vários índices (por exemplo, linkIndex) além de nameIndex , pode haver vários lugares que precisam de limpeza. Descobrir onde ocorre a falta de sincronia pode ser uma solução melhor a longo prazo.

Existe alguma maneira de limpar nomes de índices fora de sincronia?
Por enquanto, a única solução que tenho é reiniciar o nó, o que não é bom. Reinicializar o daemon do docker também não é bom.

Para mim, o que funciona é parar o daemon do docker, remover tudo de /var/lib/docker/* e iniciar o docker novamente. É um servidor de integração contínua, então posso lidar com não ter nenhuma imagem carregada no contexto do docker, então isso funciona para mim, YMMV.

Estou vendo o mesmo comportamento em 1.10.3

Containers: 105
 Running: 75
 Paused: 0
 Stopped: 30
Images: 1434
Server Version: 1.10.3
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Logging Driver: json-file
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 4.5.0-coreos-r1
Operating System: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Architecture: x86_64

Estamos vendo esse problema todos os dias no CoreOS e Docker 1.10.3:

 # journalctl -fu docker
Aug 22 12:37:53 stateless-0.novalocal dockerd[8215]: time="2016-08-22T12:37:53.857617384+10:00" level=error msg="Handler for POST /v1.22/containers/create returned error: Conflict. The name \"/bridge-clockwork\" is already in use by container a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0. You have to remove (or rename) that container to be able to reuse that name."

# docker inspect a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Error: No such image or container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

# docker rm -f a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0
Failed to remove container (a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0): Error response from daemon: No such container: a9710d980f2935638df62e67175e28078753818a8b7e1e20bd2840d738dd58c0

em 50% de todos os casos, reiniciar o daemon do docker corrige o problema. Nos outros casos, temos que rm -rf / var / lib / docker. Ambas as soluções alternativas são prejudiciais para a carga de trabalho de produção.

@cdwertmann Se você tiver que rm -rf /var/lib/docker , isso significa que existe um contêiner com esse nome e está sendo recarregado após a reinicialização do daemon. Se você estiver recebendo os mesmos erros ao tentar remover esses contêineres, seria extremamente útil ver o que há em /var/lib/docker/containers/<id>

@ cpuguy83 Aqui está o que está dentro do diretório do contêiner:

 # ls /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ -lah
total 184K
drwx------.  3 root root 4.0K Aug 20 23:14 .
drwx------. 16 root root 4.0K Aug 23 14:41 ..
-rw-r-----.  1 root root 102K Aug 23 14:39 69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log
-rw-r--r--.  1 root root 2.9K Aug 23 14:41 config.v2.json
-rw-r--r--.  1 root root  975 Aug 23 14:41 hostconfig.json
-rw-r--r--.  1 root root   17 Aug 20 23:14 hostname
-rw-r--r--.  1 root root  185 Aug 20 23:14 hosts
-rw-r--r--.  1 root root   45 Aug 20 23:14 resolv.conf
-rw-r--r--.  1 root root   71 Aug 20 23:14 resolv.conf.hash
drwx------.  2 root root 4.0K Aug 20 23:14 shm

Em config.v2.json posso ver "RemovalInProgress":true :

# cat /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/config.v2.json 
{"State":{"Running":false,"Paused":false,"Restarting":false,"OOMKilled":false,"RemovalInProgress":true,"Dead":true,"Pid":0,"ExitCode":2,"Error":"","StartedAt":"2016-08-20T13:14:17.864964407Z","FinishedAt":"2016-08-23T04:41:29.775183062Z"},"ID":"69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a","Created":"2016-08-20T13:13:58.579971761Z","Path":"/bin/registrator","Args":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Config":{"Hostname":"sphinx","Domainname":"novalocal","User":"","AttachStdin":false,"AttachStdout":true,"AttachStderr":true,"Tty":false,"OpenStdin":false,"StdinOnce":false,"Env":["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"],"Cmd":["-ip","172.16.0.102","-resync","300","consul://172.16.0.102:8500"],"Image":"registry/registrator","Volumes":null,"WorkingDir":"","Entrypoint":["/bin/registrator"],"OnBuild":null,"Labels":{},"StopSignal":"SIGTERM"},"Image":"sha256:3b59190c6c800907d7a62c245bf93888db802b00407002fff7e08fed24e5557e","NetworkSettings":{"Bridge":"","SandboxID":"7713b13649c7964520180342f99914dd4720833ed39a51793ed483c356e0bd85","HairpinMode":false,"LinkLocalIPv6Address":"","LinkLocalIPv6PrefixLen":0,"Networks":{"bridge":{"IPAMConfig":null,"Links":null,"Aliases":null,"NetworkID":"5c0baa715bb76ea2eb5a6a32deb36a8093391ba6c76e55f31768838560c10f22","EndpointID":"","Gateway":"","IPAddress":"","IPPrefixLen":0,"IPv6Gateway":"","GlobalIPv6Address":"","GlobalIPv6PrefixLen":0,"MacAddress":""}},"Ports":null,"SandboxKey":"/var/run/docker/netns/7713b13649c7","SecondaryIPAddresses":null,"SecondaryIPv6Addresses":null,"IsAnonymousEndpoint":false},"LogPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a-json.log","Name":"/registrator","Driver":"overlay","MountLabel":"system_u:object_r:svirt_lxc_file_t:s0:c631,c718","ProcessLabel":"system_u:system_r:svirt_lxc_net_t:s0:c631,c718","RestartCount":0,"HasBeenStartedBefore":true,"HasBeenManuallyStopped":false,"MountPoints":{"/etc/localtime":{"Source":"/etc/localtime","Destination":"/etc/localtime","RW":false,"Name":"","Driver":"","Relabel":"ro","Propagation":"rprivate","Named":false},"/tmp/docker.sock":{"Source":"/var/run/docker.sock","Destination":"/tmp/docker.sock","RW":true,"Name":"","Driver":"","Relabel":"","Propagation":"rprivate","Named":false}},"AppArmorProfile":"","HostnamePath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hostname","HostsPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/hosts","ShmPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/shm","ResolvConfPath":"/var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/resolv.conf","SeccompProfile":""}

Depois de excluir manualmente /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ e reiniciar o docker daemon, o conflito foi resolvido.

Vendo o mesmo aqui:

docker -v      
Docker version 1.10.3, build 3cd164c
docker-compose -v
docker-compose version 1.8.0, build f3628c7
cat /etc/os-release 
NAME=CoreOS
ID=coreos
VERSION=1068.10.0
VERSION_ID=1068.10.0
BUILD_ID=2016-08-23-0220
PRETTY_NAME="CoreOS 1068.10.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues" 

E é assim que eu inicio / paro / reinicio meus contêineres:

cat /etc/systemd/system/u\@.service 
[Unit]
Description=%p-%i

# Requirements
Requires=docker.service

# Dependency ordering
After=docker.service

[Service]
Restart=always
RestartSec=10
TimeoutStartSec=60
TimeoutStopSec=15
EnvironmentFile=-/data/domains/%i/env
WorkingDirectory=/data/domains/%i/
ExecStartPre=-/opt/bin/docker-compose rm -f
ExecStart=/bin/bash -euxc "VIRTUAL_HOST=%i /opt/bin/docker-compose up"
ExecStop=/opt/bin/docker-compose stop

[Install]
WantedBy=multi-user.target

Recebi o mesmo erro e, em seguida, nada em docker ps -a , mas havia uma pasta em /var/lib/docker/containers com o hash do contêiner, removi, ainda sem sorte. Eu reiniciei o daemon do docker, funcionou.

Esta solução alternativa para https://github.com/docker/compose/issues/3277#issuecomment -238080180 também corrige esse problema ...

@marcelmfs não é para mim. Tenho que deletar /var/lib/docker inteiros

Estranho, para mim funcionou. Vou tentar mais uma vez para ter certeza.

@marcelmfs então você acabou de deletar docker / network / files / local-kv.db?

Além disso, também removeu todos os contêineres em execução docker rm -f $(docker ps -aq) , e talvez todas as redes, já que está removendo também o network/files/local-kv.db .

Não vi esse problema desde a atualização para docker 1.12

Alguém ainda está vendo isso com 1.12.x?

Ainda preciso atualizar para verificar ... Alocarei uma janela para atualização amanhã.

Nosso servidor de CI foi atualizado e removemos a solução alternativa que estava excluindo o arquivo local-kv.db . Na próxima semana terei mais novidades sobre isso.

O mesmo aqui: tive o problema em 1.11.x, mas não mais desde 1.12.x

Sim, percebi que ninguém estava reclamando disso no 1.12.
Imagino o que mudamos, tenho certeza de que nada está diretamente relacionado à nomenclatura.

tl; dr: todas as versões> = 1.10.0 são afetadas, mas em> = 1.12.0 é muito menos provável que isso aconteça.

Eu rastreei esse problema no código e ele pode definitivamente acontecer em todas as versões> = 1.10.0 que é onde a estrutura nameIndex foi introduzida. Como @yongtang mencionou, essa estrutura fica fora de sincronia com os contêineres removidos.

O erro ocorre sempre que nameIndex fica fora de sincronia com daemon.containers .

O problema está na função Daemon.create () . nameIndex é atualizado na linha 64 por daemon.newContainer() mas daemon.containers é atualizado muito mais tarde na linha 149 por daemon.Register() .

Se algo falhar entre esses dois, o docker está em um estado inconsistente. Antes de comprometer https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (desembarcado em 1.12.0), isso era tudo o que era necessário para acionar o problema. Esse commit mudou a função de limpeza de docker.ContainerRm , que nunca funciona neste caso porque é necessário que o contêiner seja registrado , para docker.cleanupContainer .

No entanto, docker.cleanupContainer pode falhar antes de conseguir limpar. Exclui apenas entradas de nameIndex na linha 113, mas há muitas coisas que podem dar errado antes disso.

Todos os itens acima explicam o caso em que uma reinicialização simples do daemon corrige o problema porque nameIndex não é persistente no disco. Bati minha cabeça contra o código para tentar descobrir como esse bug poderia sobreviver a reinicializações, mas não consigo ver como. Nós definitivamente o vimos em produção, então, no momento, estou esperando que aconteça novamente e tento investigar mais.

Corrigi a versão na memória do problema em # 27956

Este problema apenas surgiu para mim antes de atualizar para o mais recente (1.12.3), desinstalei o docker e reinstalei e, infelizmente, ainda estou vendo.

Resultado de docker version :

Client:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      windows/amd64

Server:
 Version:      1.12.3
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   6b644ec
 Built:        Wed Oct 26 23:26:11 2016
 OS/Arch:      linux/amd64

Resultado de docker info

Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 1
Server Version: 1.12.3
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 11
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.27-moby
Operating System: Alpine Linux v3.4
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.919 GiB
Name: moby
ID: XZHZ:262M:ENKG:Z62J:U4OX:FVKN:CGZW:7OCZ:IU5R:D7OM:F3MT:K3ND
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 12
 Goroutines: 22
 System Time: 2016-11-09T01:01:32.4577814Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
Insecure Registries:
 127.0.0.0/8

Meu fluxo de trabalho é um pouco diferente do que foi mencionado neste tópico, mas é semelhante porque estou fazendo muitas configurações e desmontagens de contêineres em meu pacote de testes. Também pode ser interessante que isso esteja sendo feito por meio de solicitações à API remota.

Não sei como devo proceder. Se solicitado, certamente posso preparar um caso de teste do meu problema, mas a partir de agora é parte de um projeto maior em andamento, então vou precisar cortar coisas.

Vocês têm alguma sugestão?

@davidglivar Você reiniciou o daemon e ainda está vendo o erro?

@ cpuguy83 se ao reiniciar o daemon, você quer dizer parar / iniciar o aplicativo docker para Windows, sim. Eu também reinstalei o docker, bem como fiz uma redefinição de 'fábrica'. Não toquei no Hyper-V porque não estou confiante em seu funcionamento interno.

@davidglivar Então você está vendo isso:

1. Fazer coisas
2. obter erro
3. reinicie o docker4win
4. obter erro

?

@ cpuguy83 sim! Acabei de passar por essa sequência algumas vezes para ter certeza.

@davidglivar Você pode docker ps -a e ver se você vê o contêiner ali?

@ cpuguy83 docker ps -a não produz recipientes. Eu diria que é por causa da desmontagem e preparação do meu teste, mas mesmo quando detecto o erro em meus testes e cria imediatamente um processo filho de docker ps -a o resultado é o mesmo.

Só para acompanhar os comentários do dia anterior: Ainda encontrei o erro 409 no contexto da minha inscrição; entretanto, um script de teste ( aqui ) ainda não apresentou nenhum problema.

Criei uma maneira confiável de reproduzir isso. Você pode usar o seguinte script Python para fazer qualquer conflito de nome de contêiner:

# 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:
    pass

Esse problema também pode ser desencadeado em uma das seguintes condições, que explicam alguns dos casos em que foi necessário limpar /var/lib/docker :

• /var/lib/docker está sem inodes
• /var/lib/docker está sem espaço
• /var/lib/docker/<storage-driver> é somente leitura

A correção é atualizar para docker> = 1.12.0

Desculpe por voltar atrasado neste assunto.

Até agora, desde a remoção da solução alternativa, nosso servidor de CI não sofreu mais com esse problema.

Client:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.1
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   23cf638
 Built:
 OS/Arch:      linux/amd64

Também experimentando isso com:

CentOS 7.2
Docker 1.12.1

Não há pasta com o hash especificado em /var/lib/docker/containers , e reiniciar o daemon não teve efeito.

@orodbhen Se reiniciar o daemon não funcionou, deve haver um contêiner carregado com esse nome.
Você pode verificar docker ps -a ?

@ cpuguy83 Não, não há nenhum contêiner com esse nome.

Na verdade, acho que isso pode ser um problema com docker-py . Eu me pergunto quantas pessoas aqui estão usando. Parece que @petrosagg é.

Acontece ao chamar create_container() mesmo que o nome do contêiner incorreto não seja usado. Mas não tenho nenhum problema com o comando docker shell, usando docker create ou docker run .

Estranho, porém, porque parece estar imprimindo a mensagem de erro produzida pelo daemon.

@petrosagg você tem o mesmo problema ao usar o comando docker shell em vez de docker-py?

@orodbhen Tem certeza de que sua instância docker-py está se comunicando com o mesmo daemon que a CLI?

Há apenas um daemon em execução: Ambos usando /var/run/docker.sock .

Eu criei um problema para docker-py. Mas ainda não estou convencido de que não haja algum problema subjacente com o docker causando o problema.

@orodbhen Ao reiniciar o daemon, você consegue obter os logs da sequência de carregamento (especificamente, contêineres de carregamento)?

Isso não pode ser um problema de contagem de ref se você reiniciou o daemon. O registrador de nomes é mantido apenas na memória e é reconstruído na reinicialização do daemon.

Desculpe, por favor, desconsidere. Era um problema com a maneira como eu estava registrando os erros que parecia que o erro estava ocorrendo novamente.

@orodbhen não estou usando docker-py, só usei para criar um pequeno caso de teste reproduzível. A razão pela qual isso não acontece com a CLI do docker é porque o cliente limpa a entrada antes de passá-la para o servidor, mas eu queria ter acesso direto ao servidor e fazer com que a seção crítica falhasse.

exclua o serviço em execução em segundo plano.
docker service rm service_name
em seguida, verifique as informações do docker, ele mostra os contêineres: 0

removido, repostado em # 3277

Eu também estava enfrentando o mesmo problema com os seguintes erros:

   x Start Mongo: FAILED

-----------------------------------STDERR-----------------------------------
Error response from daemon: Cannot update container 78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886: container is marked for removal and cannot be "update"
Error response from daemon: removal of container mongodb is already in progress
docker: Error response from daemon: Conflict. The container name "/mongodb" is already in use by container "78dc6f6a43d0e6cfb7aa6bba2f0a377bd39620bff79ca308540a13ddd4e62886". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.
-----------------------------------STDOUT-----------------------------------
3.4.1: Pulling from library/mongo
Digest: sha256:aff0c497cff4f116583b99b21775a8844a17bcf5c69f7f3f6028013bf0d6c00c
Status: Image is up to date for mongo:3.4.1
no such container
Running mongo:3.4.1

Acabei de executar o comando: sudo service docker restart

E tudo está funcionando bem agora.

Eu também estava enfrentando esse problema com os seguintes erros:

docker-compose up -d --no-build api
Creating api ... 
Creating api ... error

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.

ERROR: for api  Cannot create container for service api: Conflict. The name "/api" is already in use by container 2788cdc091645f0dcef417f189f9c80fddd3f6f99eaba3771d0f4a87e2295841. You have to remove (or rename) that container to be able to reuse that name.
ERROR: Encountered errors while bringing up the project.

Acontece que o diretório onde o arquivo de composição está localizado foi renomeado no momento em que o contêiner existente foi executado e quando tentei executá-lo novamente. Eu verifiquei executando o seguinte:

docker inspect api | grep -i compose
"com.docker.compose.config-hash": "c0e3e88ad502faf806288e16419dc52b113cae18abeac1769fa0e98a741de48a",
"com.docker.compose.container-number": "1",
"com.docker.compose.oneoff": "False",
"com.docker.compose.project": "api",
"com.docker.compose.service": "api",
"com.docker.compose.version": "1.14.0"

Percebi que o rótulo do projeto foi definido como api mas o diretório atual onde eu executei isso era na verdade api.git então parece que ele foi renomeado em algum momento entre minha última execução e agora. Simplesmente renomeei o diretório de volta para api , abri o contêiner novamente (sem remover o contêiner existente ou reiniciar o docker) e tudo está funcionando conforme o esperado.

Temos muitos contêineres em execução, portanto, reiniciar o docker não foi uma solução ideal.

docker container prune para deletar contêineres parados.

Tive que forçar a remoção do contêiner docker rm -f /<container_name>