Moby: El nombre "/ data-container-name" ya lo usa el contenedor<hash>. Debe eliminar (o cambiar el nombre) de ese contenedor para poder reutilizar ese nombre.</hash>

Creado en 8 jun. 2016  ·  49Comentarios  ·  Fuente: moby/moby

Salida de docker version :

Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:11 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:11 2016
 OS/Arch:      linux/amd64

Salida de docker info :

Containers: 87
 Running: 31
 Paused: 0
 Stopped: 56
Images: 55
Server Version: 1.11.2
Storage Driver: overlay
 Backing Filesystem: xfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: null host bridge
Kernel Version: 4.5.1-1.el7.elrepo.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.797 GiB
Name: bridge.datanet.ria
ID: HKGW:2SMN:VJFA:XALB:4ETF:ZZE7:OUQJ:GVHX:SXOM:U6PY:EQLR:3P27
Docker Root Dir: /mnt/docker-data
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled

Detalles adicionales del entorno (AWS, VirtualBox, físico, etc.):
Nube privada con hipervisor VMWARE, ejecutando CentOS7.

Pasos para reproducir el problema:

  1. Implemente muchos contenedores después de limpiar completamente el contexto de la ventana acoplable, en un ciclo de implementación / integración continua.
  2. Repetir.
  3. Después de algún tiempo (generalmente de 4 a 6 días), el ciclo se rompe.

Describe los resultados que recibiste:

Jun  8 05:12:48 bridge docker: time="2016-06-08T05:12:48.799299085+02:00" level=error msg="Clean up Error! Cannot destroy container ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632: No such container: ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632"
Jun  8 05:12:48 bridge docker: time="2016-06-08T05:12:48.856161501+02:00" level=error msg="Handler for POST /v1.22/containers/create returned error: device or resource busy"
Jun  8 09:56:45 bridge docker: time="2016-06-08T09:56:45.266066521+02:00" level=error msg="Handler for POST /v1.22/containers/create returned error: Conflict. The name \"/my-redacted-data-container\" is already in use by container ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632. You have to remove (or rename) that container to be able to reuse that name."
Jun  8 10:35:42 bridge docker: time="2016-06-08T10:35:42.523718617+02:00" level=error msg="Handler for DELETE /v1.23/containers/ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632 returned error: No such container: ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632"
Jun  8 10:37:39 bridge docker: time="2016-06-08T10:37:39.492129195+02:00" level=error msg="Handler for DELETE /v1.23/containers/my-redacted-data-container returned error: No such container: my-redacted-data-container"
Jun  8 10:49:39 bridge docker: time="2016-06-08T10:49:39.924944312+02:00" level=error msg="Handler for DELETE /v1.23/containers/my-redacted-data-container returned error: No such container: my-redacted-data-container"
Jun  8 10:50:03 bridge docker: time="2016-06-08T10:50:03.114422404+02:00" level=error msg="Handler for DELETE /v1.23/containers/ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632 returned error: No such container: ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632"
Jun  8 11:03:29 bridge docker: time="2016-06-08T11:03:29.425100332+02:00" level=error msg="Handler for POST /v1.22/containers/create returned error: Conflict. The name \"/my-redacted-data-container\" is already in use by container ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632. You have to remove (or rename) that container to be able to reuse that name."
Jun  8 11:31:38 bridge docker: time="2016-06-08T11:31:38.704053754+02:00" level=error msg="Handler for POST /v1.23/containers/my-redacted-data-container/rename returned error: No such container: my-redacted-data-container"
Jun  8 11:31:49 bridge docker: time="2016-06-08T11:31:49.934637125+02:00" level=error msg="Handler for DELETE /v1.23/containers/my-redacted-data-container returned error: No such container: my-redacted-data-container"
Jun  8 11:31:51 bridge docker: time="2016-06-08T11:31:51.939043806+02:00" level=error msg="Handler for DELETE /v1.23/containers/my-redacted-data-container returned error: No such container: my-redacted-data-container"

Describe los resultados que esperabas:
Espere que el proceso de limpieza limpie todo y no reciba:

ERROR: for my-redacted-data-container  Conflict. The name "/my-redacted-data-container" is already in use by container ecb293bb1fad3948d9a7366f931a001b7abcbd9c9aefdf27c530be7a4b4cc632. You have to remove (or rename) that container to be able to reuse that name.

Información adicional que considere importante (por ejemplo, el problema ocurre solo ocasionalmente):
El problema ocurre con frecuencia, todas las semanas o según la cantidad de cambios e integraciones, incluso dos veces por semana.
Limpiar el contexto nuevamente no resuelve el problema, ni siquiera reiniciar la ventana acoplable, la única solución es detener la ventana acoplable, eliminar todo el contenido de /var/lib/docker/* (/ mnt / docker-data en mi caso) e iniciar la ventana acoplable.

kinbug statumore-info-needed versio1.11

Comentario más útil

Tengo una función de ayudante para bombardear todo de modo que nuestro ciclo de bla Continuo pueda ser probado, eh ... continuamente. Básicamente, se reduce a lo siguiente:

Para limpiar contenedores:

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

Para borrar imágenes:

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

Para borrar volúmenes:

docker volume rm $(docker volume ls -q)

Para borrar redes:

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

Todos 49 comentarios

¿Cómo limpiaste esos contenedores? ¿Se produce alguna excepción por la que limpia esos recursos (incluida la red de volumen, etc.)?

Tengo una función de ayudante para bombardear todo de modo que nuestro ciclo de bla Continuo pueda ser probado, eh ... continuamente. Básicamente, se reduce a lo siguiente:

Para limpiar contenedores:

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

Para borrar imágenes:

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

Para borrar volúmenes:

docker volume rm $(docker volume ls -q)

Para borrar redes:

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

Tengo un grupo de enjambres donde los contenedores se suben y bajan mucho para propósitos de CI y tengo el mismo problema. Sin embargo, en mi caso no necesito reiniciar la máquina, generalmente mato todos los contenedores con

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

luego reiniciando Docker

$ sudo service docker restart

y luego recrear el enjambre lo arregla.

Aquí está el registro de una falla típica. Utilizo ansible para ejecutar docker compose comandos en uno de los nodos del enjambre contra el enjambre.

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

Intenté eliminar el contenedor llamado "bookingeng811_redis1_1" manualmente pero no existe en ninguna parte.

Tengo el mismo problema allí.

Repito con frecuencia el ciclo:

  • docker stop% nombre%
  • docker rm -f% nombre%
  • docker pull% name%
  • Docker ejecutar% name%

En algún momento (2-3 días) deja de funcionar:
docker: Respuesta de error del daemon: Conflict. El nombre "% name%" ya está siendo utilizado por el contenedor% container_id% . Tienes que eliminar (o cambiar el nombre) ese contenedor para poder reutilizar ese nombre.

Cuando intento eliminar el contenedor% container_id% manualmente, dice:
Error al eliminar el contenedor (% container_id%): respuesta de error del demonio: No existe tal contenedor:% container_id%

El contenedor% container_id% no está en la lista docker ps -a y no en la carpeta / var / lib / docker / containers

¿Quizás la raíz del problema es eliminar el contenedor con el parámetro -f? por lo que Docker no se limpia correctamente y el demonio de Docker cree que el contenedor todavía está allí.


Salida de la versión de Docker:

Cliente:
Versión: 1.10.3
Versión de API: 1.22
Go versión: go1.5.3
Confirmación de Git: 8acee1b
Construido:
SO / Arch: linux / amd64

Servidor:
Versión: 1.10.3
Versión de API: 1.22
Go versión: go1.5.3
Confirmación de Git: 8acee1b
Construido:
SO / Arch: linux / amd64

Salida de información de Docker:

Contenedores: 27
Corriendo: 13
En pausa: 0
Detenido: 14
Imágenes: 1512
Versión del servidor: 1.10.3
Controlador de almacenamiento: devicemapper
Nombre de la piscina: docker-8: 9-521647-pool
Tamaño del bloque de la piscina: 65.54 kB
Tamaño del dispositivo base: 107,4 GB
Sistema de archivos de respaldo: xfs
Archivo de datos: / dev / loop2
Archivo de metadatos: / dev / loop3
Espacio de datos utilizado: 53,62 GB
Espacio de datos total: 107,4 GB
Espacio de datos disponible: 53,76 GB
Espacio de metadatos utilizado: 129,9 MB
Espacio total de metadatos: 2.147 GB
Espacio de metadatos disponible: 2.018 GB
Sincronización Udev compatible: verdadero
Eliminación diferida habilitada: falso
Eliminación diferida habilitada: falso
Recuento de dispositivos eliminados diferidos: 0
Archivo de bucle de datos: / var / lib / docker / devicemapper / devicemapper / data
ADVERTENCIA: Se desaconseja enfáticamente el uso de dispositivos de bucle invertido para uso en producción. Utilice --storage-opt dm.thinpooldev o utilice --storage-opt dm.no_warn_on_loop_devices=true para suprimir esta advertencia.
Archivo de bucle de metadatos: / var / lib / docker / devicemapper / devicemapper / metadata
Versión de la biblioteca: 1.02.93 (30/01/2015)
Controlador de ejecución: native-0.2
Controlador de registro: archivo json
Complementos:
Volumen: local
Red: puente de host nulo
Versión de Kernel: 4.5.0-coreos-r1
Sistema operativo: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Arquitectura: x86_64
CPU: 8
Memoria total: 11,74 GiB
Nombre: xx-slave
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES : VZQJ: SRZJ: JLKW

Docker usa 'nameIndex' para guardar la referencia a los contenedores. Según la descripción, parece que el problema se debe a que nameIndex está sincronizado con los contenedores eliminados. Ahí es donde se devuelve el error.

Es posible que podamos limpiar el nameIndex no sincronizado para solucionar temporalmente el problema. Aunque la ventana acoplable usa varios índices (por ejemplo, linkIndex) además de nameIndex puede haber varios lugares que necesiten limpieza. Encontrar dónde ocurre la falta de sincronización podría ser una mejor solución a largo plazo.

¿Hay alguna forma de limpiar los índices de nombres no sincronizados?
Por ahora, la única solución que tengo es reiniciar el nodo, lo cual no es bueno. Reiniciar el daemon de la ventana acoplable tampoco es bueno.

Para mí, lo que funciona es detener el demonio de Docker, eliminar todo de /var/lib/docker/* y volver a iniciar Docker. Es un servidor de integración continua, por lo que puedo manejar no tener ninguna imagen cargada en el contexto de la ventana acoplable, así que eso funciona para mí, YMMV.

Veo el mismo comportamiento en 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

Vemos este problema todos los días en CoreOS y 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

en el 50% de todos los casos, reiniciar el demonio de la ventana acoplable soluciona el problema. En los otros casos, tenemos que rm -rf / var / lib / docker. Ambas soluciones son disruptivas para la carga de trabajo de producción.

@cdwertmann Si tiene que rm -rf /var/lib/docker , eso significa que existe un contenedor con ese nombre y se recargará después de que se reinicie el demonio. Si obtiene los mismos errores al intentar eliminar estos contenedores, sería extremadamente útil ver qué hay en /var/lib/docker/containers/<id>

@ cpuguy83 Esto es lo que hay dentro del directorio del contenedor:

 # 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

En config.v2.json puedo 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":""}

Después de eliminar manualmente /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ y reiniciar el daemon de la ventana acoplable, se resolvió el conflicto.

Viendo lo mismo aquí:

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" 

Y así es como inicio / detengo / reinicio mis contenedores:

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

Recibí el mismo error, y luego, nada debajo de docker ps -a , pero había una carpeta debajo de /var/lib/docker/containers con el hash del contenedor, lo eliminé, todavía sin suerte. Reinicié el demonio de la ventana acoplable, funcionó.

Esta solución para https://github.com/docker/compose/issues/3277#issuecomment -238080180 también soluciona este problema ...

@marcelmfs no es para mí. Tengo que borrar todo el /var/lib/docker

Extraño, para mí simplemente funcionó. Lo intentaré una vez más para estar seguro.

@marcelmfs, ¿acabas de eliminar docker / network / files / local-kv.db?

No solo eso, también eliminó todos los contenedores en ejecución docker rm -f $(docker ps -aq) , y tal vez todas las redes, ya que también elimina el network/files/local-kv.db .

No he visto este problema desde que actualicé a Docker 1.12

¿Alguien más sigue viendo esto con 1.12.x?

Todavía necesito actualizar para comprobar ... Asignaré una ventana para actualizar mañana.

Nuestro servidor CI se actualizó y eliminamos la solución alternativa que eliminaba el archivo local-kv.db . La semana que viene tendré más noticias sobre esto.

Lo mismo aquí: tuve el problema en 1.11.x pero ya no desde 1.12.x

Sí, noté que nadie se quejaba de esto en 1.12.
Me pregunto qué cambiamos, estoy seguro de que no hay nada directamente relacionado con los nombres.

tl; dr: todas las versiones> = 1.10.0 se ven afectadas pero en> = 1.12.0 es mucho menos probable que suceda.

Seguí este problema en el código y definitivamente puede suceder en todas las versiones> = 1.10.0, que es donde se introdujo la estructura nameIndex . Como mencionó @yongtang , esta estructura se desincroniza con los contenedores eliminados.

El error ocurre siempre que nameIndex está sincronizado con daemon.containers .

El problema radica en la función Daemon.create () . nameIndex se actualiza en la línea 64 por daemon.newContainer() pero daemon.containers se actualiza mucho más tarde en la línea 149 por daemon.Register() .

Si algo falla entre estos dos, la ventana acoplable se encuentra en un estado inconsistente. Antes de confirmar https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (aterrizó en 1.12.0), eso era todo lo que se necesitaba para desencadenar el problema. Esa confirmación cambió la función de limpieza de docker.ContainerRm , que nunca funciona en este caso porque necesita que el contenedor esté registrado , a docker.cleanupContainer .

Sin embargo, docker.cleanupContainer puede fallar antes de que logre la limpieza. Solo borra las entradas de nameIndex en la línea 113, pero hay muchas cosas que pueden salir mal antes de eso.

Todo lo anterior explica el caso en el que un simple reinicio del demonio soluciona el problema porque nameIndex no se conserva en el disco. Me golpeé la cabeza contra el código para intentar averiguar cómo este error podría sobrevivir a los reinicios, pero no veo cómo. Sin embargo, definitivamente lo hemos visto en producción, así que actualmente estoy esperando que vuelva a suceder e intento investigar más a fondo.

Arreglé la versión en memoria del problema en # 27956

Este problema me apareció antes de actualizar a la última versión (1.12.3), desinstalé la ventana acoplable y la reinstalé, y desafortunadamente todavía lo veo.

Salida 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

Salida 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

Mi flujo de trabajo es un poco diferente de lo que se ha mencionado en este hilo, pero es similar en el sentido de que estoy haciendo mucha configuración y desmontaje de contenedores en mi suite de pruebas. También puede ser de interés que esto se haga mediante solicitudes a la API remota.

Estoy un poco perdido en cuanto a cómo proceder. Si se me solicita, ciertamente puedo preparar un caso de prueba de mi problema, pero a partir de ahora es parte de un proyecto más grande en el trabajo, así que tendré que reducir las cosas.

¿Tienen alguna sugerencia?

@davidglivar ¿Reinició el daemon y sigue viendo el error?

@ cpuguy83 si al reiniciar el demonio, te refieres a detener / iniciar la aplicación Docker para Windows, sí. También he reinstalado la ventana acoplable, además de hacer un restablecimiento de 'fábrica'. No he tocado Hyper-V porque no confío en su funcionamiento interno.

@davidglivar Entonces estás viendo esto:

  1. hacer cosas
  2. obtener error
  3. reiniciar docker4win
  4. obtener error

?

@ cpuguy83 ¡sí! Pasé por esa secuencia un par de veces para estar seguro.

@davidglivar ¿Puedes docker ps -a y ver si ves el contenedor allí?

@ cpuguy83 docker ps -a no produce contenedores. Yo diría que es debido a mi desmontaje y preparación de la prueba, pero incluso cuando detecta el error en mis pruebas e inmediatamente crea un proceso hijo de docker ps -a el resultado es el mismo.

Solo para dar seguimiento a los comentarios del día anterior: todavía encontré el error 409 en el contexto de mi solicitud; sin embargo, un script de prueba ( aquí ) aún no ha mostrado ningún problema.

Creé una forma confiable de reproducir esto. Puede usar la siguiente secuencia de comandos de Python para hacer que cualquier nombre de contenedor entre en conflicto:

# 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

Este problema también se puede desencadenar en una de las siguientes condiciones que explican algunos de los casos en los que se necesitó borrar /var/lib/docker :

  • /var/lib/docker tiene inodos
  • /var/lib/docker tiene espacio
  • /var/lib/docker/<storage-driver> es de solo lectura

La solución es actualizar a Docker> = 1.12.0

Perdón por volver tarde sobre este tema.

Hasta ahora, desde que se eliminó la solución alternativa, nuestro servidor CI ya no sufría este 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

También experimentando esto con:

CentOS 7.2
Docker 1.12.1

No hay ninguna carpeta con el hash especificado en /var/lib/docker/containers y reiniciar el demonio no tuvo ningún efecto.

@orodbhen Si reiniciar el demonio no funcionó, debe haber un contenedor cargado con ese nombre.
¿Puede comprobar docker ps -a ?

@ cpuguy83 No, no hay ningún contenedor con ese nombre.

De hecho, creo que esto puede ser un problema con docker-py . Me pregunto cuántas personas aquí lo están usando. Parece que @petrosagg es.

Ocurre al llamar a create_container() incluso si no se utiliza el nombre del contenedor infractor. Pero no tengo ningún problema con el comando de la ventana acoplable, usando docker create o docker run .

Es extraño, sin embargo, porque parece estar imprimiendo el mensaje de error producido por el daemon.

@petrosagg , ¿tiene el mismo problema al usar el comando de la shell de docker en lugar de docker-py?

@orodbhen ¿Está seguro de que su instancia de docker-py está hablando con el mismo demonio que la CLI?

Solo hay un demonio en ejecución: ambos usan /var/run/docker.sock .

Creé un problema para docker-py. Pero todavía no estoy convencido de que no haya ningún problema subyacente con la ventana acoplable que cause el problema.

@orodbhen Cuando reinicia el demonio, ¿puede tomar los registros de la secuencia de carga (específicamente cargando contenedores)?

Esto no puede ser un problema de recuento de referencias si ha reiniciado el demonio. El registrador de nombres se mantiene solo en la memoria y se reconstruye al reiniciar el demonio.

Lo siento, por favor ignore. Fue un problema con la forma en que estaba registrando errores que hizo que pareciera que el error se estaba repitiendo.

@orodbhen No estoy usando docker-py, solo lo usé para crear un pequeño caso de prueba reproducible. La razón por la que no sucede con la CLI de la ventana acoplable es porque el cliente desinfecta la entrada antes de pasarla al servidor, pero yo quería tener acceso directo al servidor y hacer que fallara la sección crítica.

elimine el servicio que se ejecuta en segundo plano.
docker service rm nombre_servicio
luego revise la información de la ventana acoplable que muestra c ontainers: 0

eliminado, publicado en # 3277

También me enfrentaba al mismo problema con los siguientes errores:

   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

Acabo de ejecutar el comando: sudo service docker restart

Y todo está funcionando bien ahora.

También me enfrentaba a este problema con los siguientes errores:

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.

Resulta que el directorio donde se encuentra el archivo de redacción se renombró desde el momento en que se ejecutó el contenedor existente y cuando intenté volver a ejecutar el contenedor. Lo verifiqué ejecutando lo siguiente:

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"

Noté que la etiqueta del proyecto estaba configurada en api pero el directorio actual donde ejecuté esto era en realidad api.git por lo que parece que se cambió el nombre en algún momento entre mi última ejecución y ahora. Simplemente cambié el nombre del directorio a api , abrí el contenedor nuevamente (sin eliminar el contenedor existente o reiniciar la ventana acoplable) y todo funciona como se esperaba.

Tenemos muchos contenedores en ejecución, por lo que reiniciar Docker no fue una solución óptima.

docker container prune para eliminar contenedores detenidos.

Tuve que forzar la eliminación del contenedor docker rm -f /<container_name>

¿Fue útil esta página
0 / 5 - 0 calificaciones