Moby: Le nom "/ data-container-name" est déjà utilisé par le conteneur<hash>. Vous devez supprimer (ou renommer) ce conteneur pour pouvoir réutiliser ce nom.</hash>

comment avez-vous nettoyé ces conteneurs? Des exceptions se produisent-elles pourquoi vous nettoyez ces ressources (y compris le réseau de volume, etc.)?

J'ai une fonction d'aide pour tout atomiser afin que notre cycle continu bla, puisse être testé, euh ... en continu. Fondamentalement, cela se résume à ce qui suit:

Pour vider les conteneurs:

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

Pour effacer les images:

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

Pour effacer les volumes:

docker volume rm $(docker volume ls -q)

Pour effacer les réseaux:

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

J'ai un groupe d'essaims où les conteneurs sont montés et descendus beaucoup à des fins de CI et j'ai le même problème. Dans mon cas, je n'ai pas besoin de redémarrer la machine, tuant généralement tous les conteneurs avec

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

puis redémarrage du docker

$ sudo service docker restart

puis recréer l'essaim le corrige.

Voici le journal d'un échec typique. J'utilise ansible pour exécuter des commandes docker compose sur l'un des nœuds de l'essaim contre l'essaim.

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

J'ai essayé de supprimer manuellement le conteneur appelé "bookingeng811_redis1_1", mais il n'existe nulle part.

J'ai le même problème là-bas.

Je répète fréquemment le cycle:

• docker stop% name%
• docker rm -f% nom%
• docker pull% name%
• docker exécuter% name%

À un moment donné (2 à 3 jours), il cesse de fonctionner:
docker: réponse d'erreur du démon: conflit. Le nom "% name%" est déjà utilisé par le conteneur% container_id% . Vous devez supprimer (ou renommer) ce conteneur pour pouvoir réutiliser ce nom.

Lorsque j'essaye de supprimer manuellement le conteneur% container_id%, il dit:
Échec de la suppression du conteneur (% container_id%): réponse d'erreur du démon: aucun conteneur de ce type:% container_id%

Le conteneur% container_id% n'est pas dans la liste docker ps -a et pas dans le dossier / var / lib / docker / containers

Peut-être que la racine du problème est la suppression du conteneur avec le paramètre -f? donc docker ne nettoie pas correctement et le démon docker pense que le conteneur est toujours là.

Sortie de la version Docker:

Client:
La dernière version: 1.10.3
Version de l'API: 1.22
Version Go: go1.5.3
Git commit: 8acee1b
Construit:
OS / Arch: linux / amd64

Serveur:
La dernière version: 1.10.3
Version de l'API: 1.22
Version Go: go1.5.3
Git commit: 8acee1b
Construit:
OS / Arch: linux / amd64

Sortie d'informations Docker:

Conteneurs: 27
Course à pied: 13
En pause: 0
Arrêté: 14
Images: 1512
Version du serveur: 1.10.3
Pilote de stockage: devicemapper
Nom de la piscine: docker-8: 9-521647-pool
Taille des blocs de piscine: 65,54 kB
Taille de l'appareil de base: 107,4 Go
Système de fichiers de sauvegarde: xfs
Fichier de données: / dev / loop2
Fichier de métadonnées: / dev / loop3
Espace de données utilisé: 53,62 Go
Espace de données total: 107,4 Go
Espace de données disponible: 53,76 Go
Espace de métadonnées utilisé: 129,9 Mo
Espace de métadonnées total: 2,147 Go
Espace de métadonnées disponible: 2,018 Go
Udev Sync pris en charge: vrai
Suppression différée activée: faux
Suppression différée activée: faux
Nombre d'appareils supprimés différés: 0
Fichier de boucle de données: / var / lib / docker / devicemapper / devicemapper / data
AVERTISSEMENT: l'utilisation de périphériques de bouclage est fortement déconseillée pour une utilisation en production. Utilisez --storage-opt dm.thinpooldev ou utilisez --storage-opt dm.no_warn_on_loop_devices=true pour supprimer cet avertissement.
Fichier de boucle de métadonnées: / var / lib / docker / devicemapper / devicemapper / metadata
Version de la bibliothèque: 1.02.93 (2015-01-30)
Pilote d'exécution: native-0.2
Pilote de journalisation: fichier json
Plugins:
Volume: local
Réseau: pont d'hôte nul
Version du noyau: 4.5.0-coreos-r1
Système d'exploitation: CoreOS 1010.5.0 (MoreOS)
OSType: linux
Architecture: x86_64
Processeurs: 8
Mémoire totale: 11,74 Gio
Nom: xx-slave
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

Docker utilise 'nameIndex' pour enregistrer la référence aux conteneurs. D'après la description, il semble que le problème soit dû au fait que nameIndex n'est pas synchronisé avec les conteneurs supprimés. C'est là que l'erreur est renvoyée.

Nous pourrons peut-être nettoyer l'index nameIndex désynchronisé pour résoudre temporairement le problème. Bien que docker utilise plusieurs index (par exemple, linkIndex) en plus de nameIndex , il peut donc y avoir plusieurs endroits à nettoyer. Trouver où se produit la désynchronisation pourrait être une meilleure solution à long terme.

Existe-t-il un moyen de nettoyer les noms d'index non synchronisés?
Pour l'instant, la seule solution que j'ai est de redémarrer le nœud, ce qui n'est pas bon. Le redémarrage du démon docker n'est pas non plus bon.

Pour moi, ce qui fonctionne est d'arrêter le démon docker, de tout supprimer de /var/lib/docker/* et de redémarrer docker. C'est un serveur d'intégration continue donc je peux gérer le fait de ne pas avoir d'image chargée dans le contexte du docker, donc cela fonctionne pour moi, YMMV.

Je vois le même comportement sur 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

Nous constatons ce problème tous les jours sur CoreOS et 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

dans 50% des cas, le redémarrage du démon docker résout le problème. Dans les autres cas, nous devons rm -rf / var / lib / docker. Les deux solutions de contournement perturbent la charge de travail de production.

@cdwertmann Si vous devez rm -rf /var/lib/docker , cela signifie qu'un conteneur existe avec ce nom et qu'il est rechargé après le redémarrage du démon. Si vous rencontrez les mêmes erreurs lorsque vous essayez de supprimer ces conteneurs, il serait extrêmement utile de voir ce qu'il y a dans /var/lib/docker/containers/<id>

@ cpuguy83 Voici ce qu'il y a dans le répertoire du conteneur:

 # 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

Dans config.v2.json, je peux voir "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":""}

Après avoir supprimé manuellement /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ et redémarré le démon docker, le conflit a été résolu.

Voir la même chose ici:

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" 

Et voici comment je démarre / arrête / redémarre mes conteneurs:

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

J'ai eu la même erreur, et puis, rien sous docker ps -a , mais il y avait un dossier sous /var/lib/docker/containers avec le hachage du conteneur, j'ai supprimé, toujours pas de chance. J'ai redémarré le démon docker, cela a fonctionné.

Cette solution de contournement pour https://github.com/docker/compose/issues/3277#issuecomment -238080180 résout également ce problème ...

@marcelmfs pas pour moi. Je dois supprimer tout le /var/lib/docker

Bizarre, pour moi, ça a marché. J'essaierai encore une fois pour être sûr.

@marcelmfs donc vous venez de supprimer docker / network / files / local-kv.db?

Non seulement cela, a également supprimé tous les conteneurs en cours d'exécution docker rm -f $(docker ps -aq) , et peut-être tous les réseaux, car il supprime également le network/files/local-kv.db .

Je n'ai pas vu ce problème depuis la mise à niveau vers docker 1.12

Est-ce que quelqu'un d'autre voit encore cela avec la 1.12.x?

J'ai encore besoin de mettre à jour pour vérifier ... Je vais allouer une fenêtre pour la mise à jour demain.

Notre serveur CI est mis à niveau et nous avons supprimé la solution de contournement qui supprimait le fichier local-kv.db . La semaine prochaine, j'aurai plus de nouvelles à ce sujet.

Idem ici: avait le problème dans 1.11.x mais plus depuis 1.12.x

Ouais, j'ai remarqué que personne ne se plaignait de cela en 1.12.
Je me demande ce que nous avons changé, je suis certain que rien n'est directement lié à la dénomination.

tl; dr: toutes les versions> = 1.10.0 sont affectées mais dans> = 1.12.0 c'est beaucoup moins probable.

J'ai tracé ce problème dans le code et cela peut certainement se produire sur toutes les versions> = 1.10.0, où la structure nameIndex été introduite. Comme @yongtang l'a mentionné, cette structure

L'erreur se produit chaque fois que nameIndex n'est plus synchronisé avec daemon.containers .

Le problème réside dans la fonction Daemon.create () . nameIndex est mis à jour à la ligne 64 par daemon.newContainer() mais daemon.containers est mis à jour beaucoup plus tard à la ligne 149 par daemon.Register() .

Si quelque chose échoue entre ces deux, le docker est dans un état incohérent. Avant de commettre https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (atterri dans 1.12.0), c'était tout ce qui était nécessaire pour déclencher le problème. Ce commit a changé la fonction de nettoyage de docker.ContainerRm , qui ne fonctionne jamais dans ce cas car il faut que le conteneur soit enregistré , à docker.cleanupContainer .

Cependant, docker.cleanupContainer peut échouer avant de réussir le nettoyage. Il ne supprime que les entrées du nameIndex à la ligne 113, mais il y a beaucoup de choses qui peuvent mal tourner avant cela.

Tout ce qui précède explique le cas où un simple redémarrage du démon résout le problème car nameIndex n'est pas conservé sur le disque. Je me suis cogné la tête contre le code pour essayer de comprendre comment ce bogue pourrait survivre aux redémarrages, mais je ne vois pas comment. Nous l'avons certainement vu en production, alors j'attends actuellement que cela se reproduise et j'essaie d'enquêter plus avant.

J'ai corrigé la version en mémoire du problème dans # 27956

Ce problème vient de surgir pour moi avant la mise à jour vers la dernière version (1.12.3), j'ai désinstallé le docker et réinstallé, et je le vois encore malheureusement.

Sortie 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

Sortie 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

Mon flux de travail est un peu différent de ce qui a été mentionné dans ce fil, mais il est similaire en ce sens que je fais beaucoup de configuration et de démontage de conteneurs dans ma suite de tests. Il peut également être intéressant que cela se fasse via des requêtes adressées à l'API distante.

Je ne sais pas trop comment procéder. Si demandé, je peux certainement préparer un cas de test de mon problème, mais à partir de maintenant, il fait partie d'un projet plus vaste au travail, donc je vais devoir réduire les choses.

Avez-vous tous des suggestions?

@davidglivar Vous avez redémarré le démon et vous voyez toujours l'erreur?

@ cpuguy83 si en redémarrant le démon, vous voulez dire arrêter / démarrer l'application docker pour Windows, oui. J'ai également réinstallé le docker, ainsi qu'une réinitialisation «d'usine». Je n'ai pas touché Hyper-V car je ne suis pas confiant dans son fonctionnement interne.

@davidglivar Vous voyez donc ceci:

1. faire des choses
2. obtenir une erreur
3. redémarrer docker4win
4. obtenir une erreur

?

@ cpuguy83 ouais ! Je viens de traverser cette séquence plusieurs fois pour être sûr.

@davidglivar Pouvez-vous docker ps -a et voir si vous voyez le conteneur là-bas?

@ cpuguy83 docker ps -a ne donne aucun conteneur. Je dirais que c'est à cause de mon démontage et de ma préparation de test, mais même en détectant l'erreur dans mes tests et en créant immédiatement un processus enfant de docker ps -a le résultat est le même.

Juste pour revenir sur les commentaires de la veille: j'ai toujours rencontré l'erreur 409 dans le cadre de ma candidature; cependant, un script de test ( ici ) n'a pas encore affiché de problème.

J'ai créé un moyen fiable de reproduire cela. Vous pouvez utiliser le script python suivant pour créer un conflit de nom de conteneur:

# 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

Ce problème peut également être déclenché dans l'une des conditions suivantes qui expliquent certains des cas où l'effacement de /var/lib/docker était nécessaire:

• /var/lib/docker est à court d'inodes
• /var/lib/docker est à court d'espace
• /var/lib/docker/<storage-driver> est en lecture seule

Le correctif consiste à mettre à jour vers docker> = 1.12.0

Désolé pour un retour tardif sur ce problème.

Jusqu'à présent, depuis la suppression de la solution de contournement, notre serveur CI n'a plus souffert de ce problème.

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

Également expérimenté avec:

CentOS 7.2
Docker 1.12.1

Il n'y a pas de dossier avec le hachage spécifié sous /var/lib/docker/containers , et le redémarrage du démon n'a eu aucun effet.

@orodbhen Si le redémarrage du démon n'a pas fonctionné, il doit y avoir un conteneur chargé avec ce nom.
Pouvez-vous vérifier docker ps -a ?

@ cpuguy83 Non, il n'y a pas de conteneur avec ce nom.

Je pense en fait que cela peut être un problème avec docker-py . Je me demande combien de personnes ici l'utilisent. Il semble que @petrosagg l' est.

Cela se produit lors de l'appel de create_container() même si le nom du conteneur incriminé n'est pas utilisé. Mais je n'ai aucun problème avec la commande docker shell, en utilisant docker create ou docker run .

Etrange, cependant, car il semble imprimer le message d'erreur produit par le démon.

@petrosagg avez-vous le même problème en utilisant la commande docker shell au lieu de docker-py?

@orodbhen Êtes-vous sûr que votre instance docker-py parle au même démon que la CLI?

Il n'y a qu'un seul démon en cours d'exécution: les deux utilisant /var/run/docker.sock .

J'ai créé un problème pour docker-py. Mais je ne suis pas encore convaincu qu'il n'y a pas de problème sous-jacent avec docker à l'origine du problème.

@orodbhen Lorsque vous redémarrez le démon, pouvez-vous récupérer les journaux de la séquence de chargement (en particulier le chargement des conteneurs)?

Cela ne peut pas être un problème de comptage de références si vous avez redémarré le démon. Le registraire de noms est conservé uniquement en mémoire et est reconstruit au redémarrage du démon.

Désolé, veuillez ignorer. C'était un problème avec la façon dont je consignais les erreurs qui donnaient l'impression que l'erreur se reproduisait.

@orodbhen Je n'utilise pas docker-py, je ne l'ai utilisé que pour créer un petit cas de test reproductible. La raison pour laquelle cela ne se produit pas avec la CLI de docker est que le client nettoie l'entrée avant de la transmettre au serveur, mais je voulais avoir un accès direct au serveur et provoquer l'échec de la section critique.

supprimer le service exécuté en arrière-plan.
service docker rm nom_service
puis ckeck les informations sur le docker, il montre les conteneurs: 0

supprimé, republié sur # 3277

J'étais également confronté au même problème avec les erreurs suivantes:

   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

Je viens d'exécuter la commande: redémarrage du menu fixe sudo service

Et tout fonctionne bien maintenant.

J'étais également confronté à ce problème avec les erreurs suivantes:

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.

Il s'avère que le répertoire où se trouve le fichier de composition a été renommé à partir du moment où le conteneur existant a été exécuté et lorsque j'ai essayé de réexécuter le conteneur. J'ai vérifié en exécutant ce qui suit:

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"

J'ai remarqué que l'étiquette du projet était définie sur api mais le répertoire actuel dans lequel je l'ai exécuté était en fait api.git , il semble donc qu'il ait été renommé entre ma dernière exécution et maintenant. J'ai simplement renommé le répertoire en api , j'ai remonté le conteneur (sans supprimer le conteneur existant ni redémarrer le docker) et tout fonctionne comme prévu.

Nous avons de nombreux conteneurs en cours d'exécution, donc le redémarrage de docker n'était pas une solution optimale.

docker container prune pour supprimer les conteneurs arrêtés.

J'ai dû forcer la suppression du conteneur docker rm -f /<container_name>