Moby: Der Name "/ data-container-name" wird bereits von container verwendet<hash>. Sie müssen diesen Container entfernen (oder umbenennen), um diesen Namen wiederverwenden zu können.</hash>

Wie haben Sie diese Behälter gereinigt? Gibt es Ausnahmen, warum Sie diese Ressourcen bereinigen (einschließlich Volume-Netzwerk usw.)?

Ich habe eine Hilfsfunktion, um alles zu zerstören, damit unser kontinuierlicher bla-Zyklus kontinuierlich getestet werden kann. Grundsätzlich läuft es auf Folgendes hinaus:

So räumen Sie Behälter:

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

So löschen Sie Bilder:

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

So löschen Sie Volumes:

docker volume rm $(docker volume ls -q)

So löschen Sie Netzwerke:

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

Ich habe einen Schwarmcluster, in dem Container für ci-Zwecke viel auf und ab gebracht werden, und ich habe das gleiche Problem. In meinem Fall muss ich die Maschine jedoch nicht neu starten und normalerweise alle Container mit töten

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

Starten Sie dann Docker neu

$ sudo service docker restart

und dann das Neuerstellen des Schwarms behebt es.

Hier ist das Protokoll eines typischen Fehlers. Ich benutze ansible, um Docker Compose-Befehle auf einem der Schwarmknoten gegen den Schwarm auszuführen.

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

Ich habe versucht, den Container "bookingeng811_redis1_1" manuell zu entfernen, aber er existiert nirgendwo.

Habe dort das gleiche Problem.

Ich wiederhole häufig den Zyklus:

• Docker Stop% Name%
• Docker rm -f% name%
• Docker ziehen% Name%
• Docker-Lauf% name%

Irgendwann (2 - 3 Tage) funktioniert es nicht mehr:
Docker: Fehlerantwort vom Daemon: Konflikt. Der Name "% name%" wird bereits von Container% container_id% verwendet . Sie müssen diesen Container entfernen (oder umbenennen), um diesen Namen wiederverwenden zu können.

Wenn ich versuche, den Container% container_id% manuell zu entfernen, heißt es:
Container konnte nicht entfernt werden (% container_id%): Fehlerantwort vom Daemon: Kein solcher Container:% container_id%

Der Container% container_id% befindet sich nicht im Listendocker ps -a und nicht im Ordner / var / lib / docker / container

Vielleicht liegt die Wurzel des Problems darin, Container mit dem Parameter -f zu entfernen? Daher räumt Docker nicht richtig auf und der Docker-Daemon glaubt, dass der Container noch vorhanden ist.

Ausgabe der Docker-Version:

Klient:
Version: 1.10.3
API-Version: 1.22
Go-Version: go1.5.3
Git Commit: 8acee1b
Gebaut:
OS / Arch: Linux / AMD64

Server:
Version: 1.10.3
API-Version: 1.22
Go-Version: go1.5.3
Git Commit: 8acee1b
Gebaut:
OS / Arch: Linux / AMD64

Docker-Info-Ausgabe:

Behälter: 27
Laufen: 13
Angehalten: 0
Gestoppt: 14
Bilder: 1512
Serverversion: 1.10.3
Speichertreiber: Devicemapper
Poolname: Docker-8: 9-521647-Pool
Poolblockgröße: 65,54 kB
Basisgerätegröße: 107,4 GB
Sichern des Dateisystems: xfs
Datendatei: / dev / loop2
Metadatendatei: / dev / loop3
Verwendeter Datenraum: 53,62 GB
Datenraum Gesamt: 107,4 GB
Verfügbarer Datenraum: 53,76 GB
Verwendeter Metadatenbereich: 129,9 MB
Metadaten-Speicherplatz Gesamt: 2,147 GB
Verfügbarer Metadatenplatz: 2.018 GB
Udev-Synchronisierung unterstützt: true
Aufgeschobene Entfernung aktiviert: false
Zurückgestelltes Löschen aktiviert: false
Anzahl der zurückgestellten gelöschten Geräte: 0
Datenschleifendatei: / var / lib / docker / devicemapper / devicemapper / data
WARNUNG: Von der Verwendung von Loopback-Geräten wird für die Verwendung in der Produktion dringend abgeraten. Verwenden Sie entweder --storage-opt dm.thinpooldev oder --storage-opt dm.no_warn_on_loop_devices=true , um diese Warnung zu unterdrücken.
Metadaten-Schleifendatei: / var / lib / docker / devicemapper / devicemapper / metadata
Bibliotheksversion: 1.02.93 (30.01.2015)
Ausführungstreiber: native-0.2
Protokollierungstreiber: JSON-Datei
Plugins:
Volumen: lokal
Netzwerk: Host Bridge null
Kernel-Version: 4.5.0-coreos-r1
Betriebssystem: CoreOS 1010.5.0 (MoreOS)
OSType: Linux
Architektur: x86_64
CPUs: 8
Gesamtspeicher: 11,74 GiB
Name: xx-Sklave
ID: LVGE: QBNA : DXFP: AWR7 : NAVO: LQLR : 7 CGF: UDOF : CTES: VZQJ : SRZJ: JLKW

Docker verwendet 'nameIndex', um den Verweis auf Container zu speichern. Aus der Beschreibung geht hervor, dass das Problem darin besteht, dass nameIndex nicht mit den entfernten Containern synchron ist. Hier wird ein Fehler zurückgegeben.

Möglicherweise können wir den nicht synchronisierten nameIndex bereinigen, um das Problem vorübergehend zu beheben. Obwohl Docker zusätzlich zu nameIndex mehrere Indizes (z. B. linkIndex) verwendet, müssen möglicherweise mehrere Stellen bereinigt werden. Auf lange Sicht könnte es eine bessere Lösung sein, herauszufinden, wo die Nicht-Synchronisierung stattfindet.

Gibt es eine Möglichkeit, nicht synchronisierte nameIndexes zu bereinigen?
Im Moment besteht die einzige Lösung darin, den Knoten neu zu starten, was nicht gut ist. Neustart Docker Daemon auch nicht gut.

Für mich funktioniert es, den Docker-Daemon zu stoppen, alles von /var/lib/docker/* entfernen und Docker erneut zu starten. Es ist ein Server für die kontinuierliche Integration, sodass ich damit umgehen kann, dass kein Image im Docker-Kontext geladen wird, sodass dies für mich funktioniert, YMMV.

Ich sehe das gleiche Verhalten am 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

Wir sehen dieses Problem jeden Tag unter CoreOS und 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

In 50% aller Fälle wird das Problem durch einen Neustart des Docker-Daemons behoben. In den anderen Fällen müssen wir -mf / var / lib / docker rm. Beide Problemumgehungen beeinträchtigen die Produktionsauslastung.

@cdwertmann Wenn Sie rm -rf /var/lib/docker müssen, bedeutet dies, dass ein Container mit diesem Namen vorhanden ist und nach dem Neustart des Dämons neu geladen wird. Wenn beim Entfernen dieser Container dieselben Fehler auftreten, ist es äußerst hilfreich zu sehen, was in /var/lib/docker/containers/<id>

@ cpuguy83 Folgendes befindet sich im Containerverzeichnis:

 # 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

In config.v2.json kann ich "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":""}

Nach dem manuellen Löschen von /var/lib/docker/containers/69d00206523a0a6a996c27d6364ec13cca7c8c1d6e615e41d9da6c675abc717a/ und dem Neustart des Docker-Daemons wurde der Konflikt behoben.

Das gleiche hier sehen:

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" 

Und so starte / stoppe / starte ich meine Container:

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

Ich habe den gleichen Fehler erhalten und dann nichts unter docker ps -a , aber es gab einen Ordner unter /var/lib/docker/containers mit dem Container-Hash, den ich entfernt habe, immer noch kein Glück. Ich habe den Docker-Daemon neu gestartet, es hat funktioniert.

Diese Problemumgehung für https://github.com/docker/compose/issues/3277#issuecomment -238080180 behebt auch dieses Problem ...

@marcelmfs nicht für mich. Ich muss das gesamte /var/lib/docker löschen

Seltsam, für mich hat es einfach funktioniert. Ich werde es noch einmal versuchen, um sicherzugehen.

@marcelmfs also hast du gerade

Nicht nur das, sondern auch alle laufenden Container docker rm -f $(docker ps -aq) und möglicherweise alle Netzwerke wurden entfernt, da auch die network/files/local-kv.db .

Ich habe dieses Problem seit dem Upgrade auf Docker 1.12 nicht mehr gesehen

Sieht das noch jemand mit 1.12.x?

Ich muss noch ein Upgrade durchführen, um zu überprüfen ... Ich werde morgen ein Fenster für das Upgrade zuweisen.

Unser CI-Server wurde aktualisiert und wir haben die Problemumgehung entfernt, mit der die Datei local-kv.db gelöscht wurde. Nächste Woche werde ich weitere Neuigkeiten dazu haben.

Gleiches hier: hatte das Problem in 1.11.x aber nicht mehr seit 1.12.x.

Ja, ich habe bemerkt, dass sich in 1.12 niemand darüber beschwert hat.
Ich frage mich, was wir geändert haben. Ich bin sicher, dass nichts direkt mit der Benennung zusammenhängt.

tl; dr: Alle Versionen> = 1.10.0 sind betroffen, aber in> = 1.12.0 ist es viel weniger wahrscheinlich, dass dies passiert.

Ich habe dieses Problem im Code verfolgt und es kann definitiv in allen Versionen> = 1.10.0 auftreten, in denen die Struktur nameIndex eingeführt wurde. Wie @yongtang erwähnt, ist diese Struktur nicht mehr mit den entfernten Containern synchron.

Der Fehler tritt immer dann nameIndex , wenn daemon.containers synchronisiert ist.

Das Problem liegt in der Funktion Daemon.create () . nameIndex wird in Zeile 64 um daemon.newContainer() aktualisiert, aber daemon.containers wird viel später in Zeile 149 um daemon.Register() aktualisiert.

Wenn zwischen diesen beiden Fehlern ein Fehler auftritt, befindet sich Docker in einem inkonsistenten Zustand. Vor dem Festschreiben von https://github.com/docker/docker/commit/114be249f022535f0800bd45987c4e9cd1b321a4 (gelandet in 1.12.0) war dies alles, was zum Auslösen des Problems erforderlich war. Durch dieses Commit wurde die Bereinigungsfunktion von docker.ContainerRm , die in diesem Fall nie funktioniert, da der Container registriert werden muss , auf docker.cleanupContainer geändert.

docker.cleanupContainer kann jedoch fehlschlagen, bevor die Bereinigung durchgeführt werden kann. Es werden nur Einträge aus nameIndex in Zeile 113 gelöscht, aber es gibt viele Dinge, die vorher schief gehen können.

Alle oben genannten Punkte erläutern den Fall, in dem ein einfacher Neustart des Daemons das Problem behebt, da nameIndex nicht auf der Festplatte gespeichert ist. Ich habe meinen Kopf gegen den Code geschlagen, um herauszufinden, wie dieser Fehler Neustarts überleben kann, aber ich kann nicht sehen, wie. Wir haben es definitiv in der Produktion gesehen, also warte ich derzeit darauf, dass es wieder passiert, und versuche, weitere Untersuchungen durchzuführen.

Ich habe die In-Memory-Version des Problems in # 27956 behoben

Dieses Problem ist für mich vor dem Update auf den neuesten Stand (1.12.3) aufgetreten. Ich habe Docker deinstalliert und neu installiert und sehe es leider immer noch.

Ausgabe von 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

Ausgabe von 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

Mein Workflow unterscheidet sich ein wenig von dem, was in diesem Thread erwähnt wurde, aber es ist insofern ähnlich, als ich in meiner Testsuite viele Container ein- und ausbaue. Es kann auch von Interesse sein, dass dies durch Anforderungen an die Remote-API erfolgt.

Ich bin etwas ratlos, wie ich vorgehen soll. Auf Anfrage kann ich sicherlich einen Testfall für mein Problem vorbereiten, aber ab sofort ist es Teil eines größeren Projekts bei der Arbeit, sodass ich die Dinge reduzieren muss.

Haben Sie Vorschläge?

@davidglivar Sie haben den Daemon neu gestartet und sehen immer noch den Fehler?

@ cpuguy83 Wenn Sie mit dem Neustart des Daemons das Anhalten / Starten des Dockers für die Windows-App meinen, ja. Ich habe auch Docker neu installiert und einen Werksreset durchgeführt. Ich habe Hyper-V nicht berührt, da ich nicht sicher bin, wie es funktioniert.

@davidglivar Du Folgendes :

1. Sachen machen
2. Fehler bekommen
3. Starten Sie docker4win neu
4. Fehler bekommen

?

@ cpuguy83 yep! Ich habe diese Sequenz nur ein paar Mal durchlaufen, um sicherzugehen.

@davidglivar Kannst du docker ps -a sehen, ob du den Container dort siehst?

@ cpuguy83 docker ps -a ergibt keine Container. Ich würde sagen, es liegt an meinem Testabbruch und meiner Vorbereitung, aber selbst wenn ich den Fehler in meinen Tests abfange und sofort einen untergeordneten Prozess von docker ps -a erstelle, ist das Ergebnis dasselbe.

Nur um die Kommentare vom Vortag weiterzuverfolgen: Ich habe im Zusammenhang mit meiner Bewerbung immer noch den Fehler 409 festgestellt. Ein Testskript ( hier ) hat jedoch noch kein Problem angezeigt.

Ich habe einen zuverlässigen Weg gefunden, dies zu reproduzieren. Sie können das folgende Python-Skript verwenden, um Konflikte mit Containernamen zu verursachen:

# 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

Dieses Problem kann auch unter einer der folgenden Bedingungen ausgelöst werden, die einige der Fälle erklären, in denen das Löschen von /var/lib/docker erforderlich war:

• /var/lib/docker hat keine Inodes mehr
• /var/lib/docker hat keinen Platz mehr
• /var/lib/docker/<storage-driver> ist schreibgeschützt

Das Update besteht darin, auf Docker> = 1.12.0 zu aktualisieren

Entschuldigen Sie die verspätete Rückkehr zu diesem Thema.

Seit dem Entfernen der Problemumgehung hatte unser CI-Server bisher kein Problem mehr.

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

Erleben Sie dies auch mit:

CentOS 7.2
Docker 1.12.1

Es gibt keinen Ordner mit dem angegebenen Hash unter /var/lib/docker/containers , und ein Neustart des Dämons hatte keine Auswirkungen.

@orodbhen Wenn ein Neustart des Dämons nicht funktioniert hat, muss ein Container mit diesem Namen geladen sein.
Können Sie docker ps -a überprüfen?

@ cpuguy83 Nein, es gibt keinen Container mit diesem Namen.

Ich denke tatsächlich, dass dies ein Problem mit docker-py . Ich frage mich, wie viele Leute hier es benutzen. Es scheint, dass @petrosagg ist.

Dies passiert beim Aufrufen von create_container() auch wenn der Name des betreffenden Containers nicht verwendet wird. Aber ich habe kein Problem mit dem Docker-Shell-Befehl, der docker create oder docker run .

Seltsam, weil es die vom Daemon erzeugte Fehlermeldung zu drucken scheint.

@petrosagg Haben Sie das gleiche Problem mit dem Docker-Shell-Befehl anstelle von Docker-Py?

@orodbhen Sind Sie sicher, dass Ihre Docker-

Es läuft nur ein Daemon: Beide verwenden /var/run/docker.sock .

Ich habe ein Problem für Docker-Py erstellt. Ich bin jedoch noch nicht davon überzeugt, dass Docker das Problem nicht verursacht.

@orodbhen Können Sie beim Neustart des Dämons die Protokolle aus der

Dies kann kein Problem beim Nachzählen sein, wenn Sie den Dämon neu gestartet haben. Der Namensregistrator wird nur im Speicher gespeichert und beim Neustart des Dämons neu erstellt.

Entschuldigung, bitte ignorieren Sie. Es war ein Problem mit der Art und Weise, wie ich Fehler protokollierte, das den Anschein erweckte, dass der Fehler erneut auftrat.

@orodbhen Ich verwende Docker-

Löschen Sie den im Hintergrund ausgeführten Dienst.
Docker-Dienst rm Dienstname
dann ckeck docker info es zeigt c ontainer: 0

entfernt, neu gepostet auf # 3277

Ich hatte auch das gleiche Problem mit folgenden Fehlern:

   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

Ich habe gerade den Befehl ausgeführt: sudo service docker restart

Und jetzt funktioniert alles gut.

Ich war auch mit folgenden Problemen mit diesem Problem konfrontiert:

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.

Es stellt sich heraus, dass das Verzeichnis, in dem sich die Compose-Datei befindet, ab dem Zeitpunkt, zu dem der vorhandene Container ausgeführt wurde und als ich versuchte, den Container erneut auszuführen, umbenannt wurde. Ich habe Folgendes überprüft:

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"

Ich habe festgestellt, dass das Projektlabel auf api aber das aktuelle Verzeichnis, in dem ich es ausgeführt habe, war tatsächlich api.git Es scheint also, dass es irgendwann zwischen meinem letzten Lauf und jetzt umbenannt wurde. Ich habe das Verzeichnis einfach wieder in api , den Container wieder aufgerufen (ohne den vorhandenen Container zu entfernen oder Docker neu zu starten) und alles funktioniert wie erwartet.

Wir haben viele Container, daher war ein Neustart von Docker keine optimale Lösung.

docker container prune zum Löschen gestoppter Container.

Ich musste das Entfernen des Containers docker rm -f /<container_name> erzwingen