Moby: Netzwerk "hat aktive Endpunkte" kann nicht entfernt werden

Dieses Problem scheint sehr intermittierend zu sein und tritt nicht sehr oft auf.

@rmb938 wir hatten ein paar Probleme mit baumelnden Endpunkten und wurden über #17191 behoben. RC2 sollte dafür einen Fix haben (oder den neuesten Master). Für RC1-Tester (großen Dank) benötigen wir möglicherweise einen zusätzlichen Workaround, um die Zustände vor dem Starten von RC2 zu bereinigen. Wir werden mit den richtigen Dokumenten aktualisieren.

Fantastisch. Vielen Dank.

@mavenugo Ich habe dies gerade in 1.10.0 reproduziert:

scheint, dass #17191 keine vollständige Lösung war ...

Haben Sie einen Workaround? Selbst das Bouncen des Docker-Daemons scheint die Dinge nicht zu lösen.

(und lassen Sie es mich wissen, wenn ich Ihnen mehr Debug-Informationen besorgen kann, es wird immer noch auf meinem Computer repro't)

Ich habe dies auch gerade in 1.10.3 reproduziert und bin hier über Google gelandet, um nach einer Lösung zu suchen. Ich kann die Trennung der aktiven Endpunkte nicht erzwingen, da keiner der über docker network inspect aufgelisteten Container noch existiert.

Ich musste schließlich meinen Konsul-Container neu erstellen und den Docker-Daemon neu starten.

ping @mavenugo möchten Sie, dass dieses Problem erneut geöffnet wird, oder bevorzugen Sie ein neues Problem, falls es eine andere Ursache hat?

Klarstellung, Docker 1.10.1

Client:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   9e83765
 Built:        Fri Feb 12 12:41:05 2016
 OS/Arch:      linux/arm

Server:
 Version:      1.10.1
 API version:  1.22
 Go version:   go1.4.3
 Git commit:   9e83765
 Built:        Fri Feb 12 12:41:05 2016
 OS/Arch:      linux/arm

Lassen Sie mich das zur Untersuchung wieder öffnen

Madhu, Ihnen zugewiesen, aber Sie können es gerne neu zuweisen, oder weisen Sie auf die entsprechende Problemumgehung hin, wenn sie bereits vorhanden ist :smile:

@keithbentrup @brendandburns danke, dass du das Problem angesprochen hast . Paar Fragen

1. Verwenden Sie einen Multi-Host-Netzwerktreiber (z. B. einen Overlay-Treiber). Können Sie bitte die Ausgabe von docker network ls teilen.
2. Wenn Sie keinen Multi-Host-Treiber verwenden, können Sie dann bitte die Datei /var/lib/docker/network/files/local-kv.db (über eine File-Sharing-Website) teilen und welche network Sie entfernen möchten? Und wie entstand das Netzwerk ursprünglich?

Zu Ihrer Information. Für einen Multi-Host-Netzwerktreiber verwaltet Docker die Endpunkte für ein Netzwerk im gesamten Cluster im KV-Store. Wenn also auf einem Host in diesem Cluster noch ein Endpunkt in diesem Netzwerk aktiv ist, wird dieser Fehler angezeigt, und dies ist eine erwartete Bedingung.

@thaJeztah PTAL mein Kommentar oben und basierend auf dem Szenario muss dies kein Fehler sein. Ich bin in Ordnung, dieses Thema offen zu halten, wenn das hilft.

@mavenugo Ja, ich verwende den Overlay-Treiber über docker-compose mit einem

Als ich das Netzwerk auf jedem einzelnen Knoten docker network inspect , hatte 1 Knoten 1 Container aufgelistet, der nicht mehr existierte und daher nicht von docker rm -fv mit dem Containernamen oder der ID entfernt werden konnte.

@keithbentrup Dies ist ein veralteter Endpunktfall. Haben Sie zufällig das Fehlerprotokoll, als dieser Container ursprünglich entfernt wurde (der den Endpunkt in diesem Zustand belassen hat)?
Übrigens, wenn der Container entfernt wird, aber der Endpunkt immer noch angezeigt wird, kann man die Trennung des Endpunkts mit docker network disconnect -f {network} {endpoint-name} erzwingen. Sie können den Endpunktnamen docker network inspect {network} Befehl

@brendandburns können Sie bitte helfen, auf https://github.com/docker/docker/issues/17217#issuecomment -195739573 zu antworten?

@mavenugo Entschuldigung für die Verspätung. Ich verwende kein Docker-Multi-Host-Netzwerk afaik. Es ist ein Single-Node-Raspberry-Pi und ich habe nichts anderes getan, als Docker über Hypriot zu installieren.

Hier ist die von Ihnen angeforderte Ausgabe ( network ist das Netzwerk, das ich nicht löschen kann)

$ docker network ls
NETWORK ID          NAME                DRIVER
d22a34456cb9        bridge              bridge              
ef922c6e861e        network             bridge              
c2859ad8bda4        none                null                
150ed62cfc44        host                host 

Die kv-Datei ist angehängt, ich musste sie .txt nennen, um Github-Filter zu umgehen, aber es ist die Binärdatei.

local-kv.db.txt

Ich habe das Netzwerk über direkte API-Aufrufe erstellt (Dockerode)

Dies hat viele Male funktioniert (erstellen und löschen), ich denke, in diesem Fall habe ich docker rm -f <container-id> aber ich bin mir nicht sicher, ich habe die Maschine möglicherweise aus- und wieder eingeschaltet ...

Ich hoffe, das hilft.
--brendan

@mavenugo Wenn Sie mit docker network disconnect -f {network} {endpoint-name} docker network disconnect [OPTIONS] NETWORK CONTAINER pro docker network disconnect --help meinen, habe ich das versucht, aber es hat sich (nicht überraschend) mit No such container beschwert.

Wenn Sie EndpointID anstelle des Containernamens/der Container-ID gemeint haben, habe ich das nicht versucht (aber beim nächsten Mal), weil das nicht das ist, was die --help vorgeschlagen haben.

@keithbentrup Ich meinte die Option -f die in v1.10.x verfügbar ist. Die Option Force berücksichtigt auch den Endpunktnamen von anderen Knoten im Cluster. Daher funktionieren meine früheren Anweisungen mit der Option -f wenn Sie Docker v1.10.x verwenden.

@brendandburns danke für die Info und es ist sehr nützlich, das Problem

@mavenugo froh, dass es geholfen hat. In der Zwischenzeit, wenn ich diese Datei wegblase, wird es dann noch funktionieren?

Danke
--brendan

@brendandburns ja. bitte fahre fort. es wird einfach gut für dich funktionieren.

@mavenugo ich glaube du hast mich falsch verstanden. Ich habe die Option -f (in meinem Shell-Verlauf überprüft) in v1.10.x verwendet, aber mit der Container-ID (nicht der Endpunkt-ID) b/c, was die Hilfe vorschlägt (der Container nicht der Endpunkt). Wenn es entweder mit der Container-ID oder der Endpunkt-ID funktionieren soll, ist dies ein Fehler, b/c es wird sicherlich nicht mit der Container-ID und der Option -f wenn der Container nicht mehr existiert.

Ich konnte beim Versuch, docker_gwbridge zu entfernen, eine Bedingung wiederherstellen, die die Verwirrung lindern könnte.
Als ich den Docker-Client verwendet habe, der auf einen Schwarmmanager verweist, habe ich diese Ausgabe erlebt:

~/D/e/m/compose (develop) $ docker network inspect docker_gwbridge
[
    {
        "Name": "docker_gwbridge",
        "Id": "83dfeb756951d3d175e9058d0165b6a4997713c3e19b6a44a7210a09cd687d54",
        "Scope": "local",
        "Driver": "bridge",
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1/16"
                }
            ]
        },
        "Containers": {
            "41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f": {
                "Name": "gateway_41ebd4fc365a",
                "EndpointID": "1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c",
                "MacAddress": "02:42:ac:12:00:02",
                "IPv4Address": "172.18.0.2/16",
                "IPv6Address": ""
            }
        },
        "Options": {
            "com.docker.network.bridge.enable_icc": "false",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.name": "docker_gwbridge"
        }
    }
]
~/D/e/m/compose (develop) $ docker network disconnect -f docker_gwbridge 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
Error response from daemon: No such container: 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
~/D/e/m/compose (develop) $ docker network disconnect -f docker_gwbridge 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
Error response from daemon: No such container: 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
~/D/e/m/compose (develop) $ docker network rm docker_gwbridge
Error response from daemon: 500 Internal Server Error: network docker_gwbridge has active endpoints

Ich habe zuerst versucht, den Container nach dem Containernamen (nicht gezeigt), dann nach der ID und dann nach der Container-Endpunkt-ID zu entfernen. Keine war erfolgreich. Dann habe ich mich beim Docker-Host angemeldet und den lokalen Docker-Client verwendet, um Befehle über den Docker-Unix-Socket auszugeben:

root@dv-vm2:~# docker network disconnect -f docker_gwbridge 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f
Error response from daemon: endpoint 41ebd4fc365ae07543fd8454263d7c049d8e73036cddb22379ca1ce08a65402f not found
root@dv-vm2:~# docker network disconnect -f docker_gwbridge 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c
Error response from daemon: endpoint 1cb2e4e3431a4c2ce1ed7c0ac9bc8dee67c06982344a75312e20e4a7d6e8972c not found
root@dv-vm2:~# docker network rm docker_gwbridge
Error response from daemon: network docker_gwbridge has active endpoints
root@dv-vm2:~# docker network disconnect -f docker_gwbridge gateway_41ebd4fc365a
root@dv-vm2:~# docker network rm docker_gwbridge
root@dv-vm2:~# docker network inspect docker_gwbridge
[]
Error: No such network: docker_gwbridge

1) Beachten Sie die Ausgabe von swarm vs. direct docker client: swarm bezieht sich auf Container; docker bezieht sich auf Endpunkte. Das sollte wohl konsequent gemacht werden.
2) Die einzige erfolgreiche Option war die Angabe eines Endpunktnamens (nicht Containername oder ID oder Endpunkt-ID). Das --help sollte klarstellen, dass mehrere Eingaben akzeptabel gemacht werden sollten.
3) Ich habe den Endpunktnamen nicht mit swarm getestet, daher weiß ich nicht, ob das funktioniert hätte.

@keithbentrup das ist richtig. wie ich vorhin vorgeschlagen habe. die docker network disconnect -f {network} {endpoint-name} ... verwenden bitte den Endpunktnamen. Wir können dies verbessern, um auch endpoint-id zu unterstützen. Aber ich wollte bestätigen, dass Sie mit der Force-Option Fortschritte machen konnten.

@mavenugo, aber was Sie vorschlagen, ist nicht das, was die Hilfe sagt. außerdem fehlt ihm die Konsistenz der meisten cmds, bei denen id/name austauschbar sind.

Wenn andere diesen Thread nicht finden, werden andere dasselbe Problem wiederholen. Bevor Sie also die Unterstützung für endpoint-id hinzufügen, beheben Sie die --help .

@keithbentrup wir werden sowohl die --help als auch die Funktionalität reparieren.

Ich habe dieses Problem gerade mit Docker v1.11.2 beim Versuch docker-compose down reproduziert.
Ein früherer Versuch, docker-compose down auszuführen, hat das app_front-Netzwerk geschlossen.

$ docker-compose down
Removing network app_front
WARNING: Network app_front not found.
Removing network app_back
ERROR: network app_back has active endpoints

$ docker network inspect app_back                                                            
[                                                                                                    
    {                                                                                                
        "Name": "app_back",                                                                  
        "Id": "4a8d557eda7ce06d222fc0a9053069f44e75d25147300796686522a872261245",                    
        "Scope": "local",                                                                            
        "Driver": "bridge",                                                                          
        "EnableIPv6": false,                                                                         
        "IPAM": {                                                                                    
            "Driver": "default",                                                                     
            "Options": null,                                                                         
            "Config": [                                                                              
                {                                                                                    
                    "Subnet": "172.22.0.0/16",                                                       
                    "Gateway": "172.22.0.1/16"                                                       
                }                                                                                    
            ]                                                                                        
        },                                                                                           
        "Internal": false,                                                                           
        "Containers": {                                                                              
            "702e9916e86b7f77af363014134f160a8dcd189399719e062069c10f735cb927": {                    
                "Name": "app_db_1",                                                          
                "EndpointID": "1decedbca5bc704be84f19e287926361d196d20fe2a9bbf092ab15b37b856b3a",    
                "MacAddress": "02:42:ac:16:00:02",                                                   
                "IPv4Address": "172.22.0.2/16",                                                      
                "IPv6Address": ""                                                                    
            }                                                                                        
        },                                                                                           
        "Options": {},                                                                               
        "Labels": {}                                                                                 
    }                                                                                                
]                                                                                                    

Docker-Infos

Containers: 17                                                                                   
 Running: 1                                                                                      
 Paused: 0                                                                                       
 Stopped: 16                                                                                     
Images: 140                                                                                      
Server Version: 1.11.2                                                                           
Storage Driver: aufs                                                                             
 Root Dir: /mnt/sda1/var/lib/docker/aufs                                                         
 Backing Filesystem: extfs                                                                       
 Dirs: 245                                                                                       
 Dirperm1 Supported: true                                                                        
Logging Driver: json-file                                                                        
Cgroup Driver: cgroupfs                                                                          
Plugins:                                                                                         
 Volume: local                                                                                   
 Network: bridge null host                                                                       
Kernel Version: 4.4.12-boot2docker                                                               
Operating System: Boot2Docker 1.11.2 (TCL 7.1); HEAD : a6645c3 - Wed Jun  1 22:59:51 UTC 2016    
OSType: linux                                                                                    
Architecture: x86_64                                                                             
CPUs: 1                                                                                          
Total Memory: 1.955 GiB                                                                          
Name: default                                                                                    
ID: LKRP:E2TX:KNVZ:UD4M:FIGG:ZROO:CIA5:WBKH:RNUB:KXTQ:E6DC:545P                                  
Docker Root Dir: /mnt/sda1/var/lib/docker                                                        
Debug mode (client): false                                                                       
Debug mode (server): true                                                                        
 File Descriptors: 18                                                                            
 Goroutines: 38                                                                                  
 System Time: 2016-06-15T22:44:13.34779866Z                                                      
 EventsListeners: 0                                                                              
Username: tohagan                                                                                
Registry: https://index.docker.io/v1/                                                            
Labels:                                                                                          
 provider=virtualbox                                                                             

Ich habe einige Probleme, wenn ich versuche, Schwarm-Overlay-Endpunkte zu trennen.

Fehlerantwort vom Daemon: Netzwerk es-swarm-overlay hat aktive Endpunkte

@rmb938 Bitte sagen Sie, was falsch ist? können andere Probleme mit diesen Fragen haben?

@mavenugo

docker network disconnect -f  [Network-Name] [Endpoint-Name] 

Das hat bei mir funktioniert.

Ich habe möglicherweise das gleiche Problem mit docker 1.13.0 .

Da niemand in diesem Thread ein Beispiel dafür gegeben hat, was ich getan habe, werde ich es posten.

Bei Completes ist dies der Fehler, der es startet. Es kann daran liegen, dass ich codekitchen/dinghy-http-proxy:2.5.0 das auf Port 80 lauscht.

$ docker-compose -f deploy/docker-compose/docker-compose.yml
Creating network "dockercompose_default" with the default driver
Creating dockercompose_front-end_1
# and so on..

ERROR: for edge-router  Cannot start service edge-router: driver failed programming external connectivity on endpoint dockercompose_edge-router_1 (3ed8fb6cf4bc221dce615a9a3c5b8e4f0f8332e00e6c6d9b9f9bf0b09da57b36): Bind for 0.0.0.0:80 failed: port is already allocated
ERROR: Encountered errors while bringing up the project.

Und versuchen, alles zu Fall zu bringen:

$ docker-compose -f deploy/docker-compose/docker-compose.yml down
Stopping dockercompose_front-end_1
# and so on..
ERROR: network dockercompose_default has active endpoints

Und wie ich das Netzwerk getötet habe:

$ docker network inspect dockercompose_default
[
    {
        "Name": "dockercompose_default", # <--- Param 1
        "Id": "dd1326487a637df8a4a7a11856864a0059fca45cb63e8363bfe5196082d42d6e",
        "Created": "2017-02-08T00:22:41.341653339Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Containers": {
            "ea7a142c113700145e894c950b18fd4dec8a53e04a45045f1fb71c47eae1a13b": {
                "Name": "dinghy_http_proxy", # <--- Param 2
                "EndpointID": "38f362af8b22e575cc987f68399a97f3ed10abf2c4cc365460dba768f2df8daa",
                "MacAddress": "02:42:ac:12:00:0d",
                "IPv4Address": "172.18.0.13/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {}
    }
]

$ docker network disconnect -f dockercompose_default dinghy_http_proxy
$ docker network rm dockercompose_default
dockercompose_default

@nicolaiskogheim hat eine gültige Lösung. Mein Team hat jedoch eine Docker-Compose-Datei mit ~ 20 Containern. Also habe ich eine andere Lösung gefunden.

Ich möchte hinzufügen, dass Sie auch den Docker-Daemon neu starten können (zB systemctl restart docker auf Centos) und dann sind die Verbindungen zwischen Netzwerk und Containern weg. Sie können dann mit Erfolg docker system prune -f .

@mdotson @nicolaiskogheim bitte öffnen Sie eine neue Ausgabe; Obwohl die Fehlermeldung dieselbe ist, wurde das hier besprochene ursprüngliche Problem behoben. Sehen Sie dies nur, wenn Sie Docker Compose verwenden? In diesem Fall könnte es auch ein Problem in der Reihenfolge sein, in der Docker Compose Aktionen ausführt?

@thaJeztah Nur mit

Ich bin mir nicht sicher, aber ich denke, die meisten Leute googeln eine Fehlermeldung und werden hierher kommen, um nach einigen Befehlen zum Kopieren und Einfügen zu suchen, um ihr Problem zu beheben.

Ich hatte das gleiche Problem wie @nicolaiskogheim und @mdotson , mein influxdb-Container hatte keinen Speicher mehr und wurde ungesund. Ich konnte es nicht entfernen, stoppen oder entfernen (ich konnte es mit dem Force-Modus entfernen).
Danach habe ich versucht Docker noch einmal mit docker-compose zu starten:

# docker-compose -f /etc/docker/docker-compose.yml up -d
Creating influxdb1

ERROR: for influxdb  Cannot start service influxdb: service endpoint with name influxdb1 already exists
ERROR: Encountered errors while bringing up the project.

als versucht, das Netzwerk zu löschen:

# docker network rm 834ea759c916
Error response from daemon: network docker_default has active endpoints

und dann habe ich @nicolaiskogheim Lösung

# docker network disconnect -f docker_default influxdb1

Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.13.1
 API version:  1.26 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   092cba3
 Built:        Wed Feb  8 06:50:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

docker-compose version 1.11.1, build 7c5d5e4
docker-py version: 2.0.2
CPython version: 2.7.12
OpenSSL version: OpenSSL 1.0.2g  1 Mar 2016

Docker Service Restart hat das Problem bei mir behoben.

sudo service docker restart

docker network rm <network name>

Ich sehe das gleiche Problem beim Versuch, einen Stapel zu entfernen:

> sudo docker stack rm my-stack
Removing network my-stack_default
Failed to remove network g0450dknntdsfj1o055mk4efm: Error response from daemon: network my-stack_default has active endpointsFailed to remove some resources

Ich hatte den Stack zuerst so erstellt:

sudo docker stack deploy -c docker-compose.yml --with-registry-auth my-stack

Benutze diese Version:

Client:
 Version:      17.03.1-ce
 API version:  1.27
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.1-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.7.5
 Git commit:   c6d412e
 Built:        Mon Mar 27 17:14:09 2017
 OS/Arch:      linux/amd64
 Experimental: false

Glücklicherweise behebt sudo service docker restart es, aber immer noch kein ideales Verhalten.

Ist in 17.07.0-ce darauf gestoßen, disconnect Ansatz hat nicht funktioniert, dann Docker neu gestartet und rm erneut erfolgreich ausgeführt.

Ich bin auch mit einem 17.06-ce-Schwarmcluster darauf gestoßen; außer dem Neustart keine Optionen mehr.

sudo service docker restart es für mich auf Ubuntu, sodass ich meine Container erneut bereitstellen und starten kann.

Funktioniert auch, wenn einer der Container sich weigert, getötet zu werden (geschieht mehr als ich hoffe). Ärgerlich, da ich alle Dienste wegen eines schelmischen Containers herunterfahren muss.

Habe dieses Problem auch in 17.09.0-ce. Öffnen Sie das wieder!

Das passierte mir oft in einer Umgebung mit wenig Speicher. Sehen Sie, ob das Hinzufügen von Speicher es besser macht, meine Prozesse stoppen jetzt normal.

@tomholub Nein, Speicher ist nicht das Problem. Aber Docker Service neu gestartet, dann konnte ich das Netzwerk entfernen.

Dieses Problem tritt immer noch von Zeit zu Zeit auf, wenn versucht wird, aktiv arbeitenden Container zu stoppen und zu entfernen. (Docker für Mac Version 17.09.0-ce-mac35 (19611) Kanal: stabil a98b7c1b7c)

Client:
 Version:      17.09.0-ce
 API version:  1.32
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:40:09 2017
 OS/Arch:      darwin/amd64

Server:
 Version:      17.09.0-ce
 API version:  1.32 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   afdb6d4
 Built:        Tue Sep 26 22:45:38 2017
 OS/Arch:      linux/amd64
 Experimental: false

$ uname -a
Darwin Alexei-Workstation.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64

Normalerweise verschwindet es jedoch, wenn ich eine zufällige Anzahl von Sekunden warte. Aber es ist immer noch da.

Übrigens. Bei mir passierte es während docker-compose down --volumes --remove-orphans

Wenn Sie diese "verwaisten Netzwerke" immer noch sehen, können Sie @rmb938 @thaJeztah wieder öffnen ?

Fehlerantwort vom Daemon: Netzwerk abcd_default ID 3f2f1a6cb1cee2d82f2e2e59d10a099834a12b18eb7e3e48d6482d758bd93617 hat aktive Endpunkte

docker version
Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:23:31 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:19:04 2017
 OS/Arch:      linux/amd64

Die einzige Möglichkeit, sie zu beschneiden, scheint ein Neustart des Motors zu sein

Viel Glück heute

docker-compose down
Removing network gen365cms_default
ERROR: network gen365cms_default id b6c51b1a83ee2b938ee1c7f7148347dc9ef80a8d8ed93334873f1f84b3f27c04 has active endpoints

docker version
Client:
 Version:   17.12.0-ce-rc4
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    6a2c058
 Built: Wed Dec 20 15:53:52 2017
 OS/Arch:   darwin/amd64

Server:
 Engine:
  Version:  17.12.0-ce-rc4
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   6a2c058
  Built:    Wed Dec 20 15:59:49 2017
  OS/Arch:  linux/amd64
  Experimental: true

Dies ist immer noch reproduzierbar auf Docker version 18.06.1-ce, build e68fc7a
Es scheint, dass selbst wenn die Container einer Compose-Datei entfernt werden, ihre Endpunkte manchmal nicht entfernt werden, was manchmal bei Stromausfall passieren kann, sodass Composes entweder nicht vollständig gestartet oder vollständig entfernt werden.

Wenn kein Befehl funktioniert, dann tun Sie
sudo service docker restart
dein problem wird gelöst

Oder sudo reboot -f . Funktioniert 100%.

ich hatte heute ein ähnliches Problem. Was ich tat, war, dass ich "docker container ls -a" ausführte und sah, dass nur wenige Container, die noch liefen, das Netzwerk nutzten, das ich über den Docker-Stack gestartet hatte. Als ich diese Container manuell gelöscht habe, konnte ich das Netzwerk löschen

Ich glaube, ich bin gerade auf das Problem gestoßen , das hier erwähnt Docker version 18.09.2, build 6247962 und habe docker-compose -f $PATH_TO_MY_CONFIG down und die folgende Fehlermeldung erhalten:

ERROR: error while removing network: network michaelmoore_default id 6838b92e60a83f53c5637065e449f9124a2f297c482f1a7326cf247bfd38f70c has active endpoints

Ich habe gestern Abend tatsächlich meinen Laptop-Akku sterben lassen, was ich selten tue, und nach dem Neustart von Docker konnte ich den gleichen Befehl zum Verfassen "down" erfolgreich ausführen.

Das mag für manche offensichtlich sein, aber für mich war es das nicht, ich dachte nur, ich würde es teilen.

Ich musste nur docker-compose rm ausführen - docker-compose down ist das, was ich normalerweise mache und ps -a zeigte keine Container, also hat mich das wirklich gestolpert, bis ich das rm Cmd ausgeführt habe . Dachte, ich würde es teilen.

Ich habe am Ende das gleiche Problem, da das Netzwerk nicht mit allen Aktionen entfernen konnte, das Notieren hat geholfen. meine Version ist Docker Version 18.09.6, Build 481bc77

Um das zu beheben, habe ich Docker-Dienste neu gestartet. durch "sudo service docker restart" danach kann ich mit "docker network rm {network}" entfernen

@danwdart Ein weiterer Grund dafür sind baumelnde Container. Um sie zu entfernen, verwenden Sie den Befehl docker-compose down --remove-orphans , der den Zweck erfüllen sollte.

Hallo aus 2019, @mavenugo Ich möchte meinen aufrichtigen, aufrichtigen Dank weitergeben, dass ich die Lösung zu diesem hier im Jahr 2016 hatte.

Das ist auch nach mehr als vier Jahren immer noch ein Thema. Gibt es eine einfachere Möglichkeit, jeden Container von jedem Netzwerk zu trennen, mit dem er verbunden ist, als ein Shell-Skript mit mehr als 10 Zeilen? FWIW das scheint zu funktionieren:

#!/usr/bin/env bash

set -o errexit -o nounset -o pipefail

trap 'rm --recursive "$workspace"' EXIT
workspace="$(mktemp --directory)"
error_log="${workspace}/error.log"

for container_id in $(docker ps --all --quiet)
do
    readarray -t network_names < <(docker inspect "$container_id" | jq --raw-output '.[] | .NetworkSettings.Networks | if . == null then empty else keys | .[] end')
    for network_name in "${network_names[@]}"
    do
        echo "Disconnecting container ${container_id} from network ${network_name}."
        exit_code=0
        docker network disconnect "$network_name" "$container_id" 2> "$error_log" || exit_code="$?"
        if [[ "$exit_code" -ne 0 ]]
        then
            if grep --fixed-strings --quiet --regexp 'not connected to network' --regexp 'not connected to the network' "$error_log"
            then
                echo 'Ignoring "not connected" error…'
            else
                cat "$error_log" >&2
                exit "$exit_code"
            fi
        fi
    done
done

Zusammenfassend:

1. Richten Sie eine Falle ein, um den Arbeitsbereich beim Verlassen zu entfernen.
2. Erstellen Sie den Arbeitsbereich.
3. Für jeden Behälter:
   
   
   
   1. Für jedes Netzwerk ist der Container verbunden mit:
      
      
      
      
      
      1. Versuchen Sie, die Verbindung zu trennen.
      
      
      
      2. Wenn die Trennung fehlschlägt, weil sie noch nicht mit dem Netzwerk verbunden ist, ignorieren Sie den Fehler (leider scheint es zufällig zu sein, ob "the" Teil dieser Fehlermeldung ist). Ansonsten scheitern.
      
      
      
   
   

Eine Kombination aus der @mavenugo- Lösung und Docker-Netzwerk-Prune, nachdem alles vom Netzwerk getrennt wurde, funktioniert für mich.

Noch ein Dankeschön @mavenugo hier ab 2020

@mavenugo Wenn Sie mit docker network disconnect -f {network} {endpoint-name} docker network disconnect [OPTIONS] NETWORK CONTAINER pro docker network disconnect --help meinen, habe ich das versucht, aber es hat sich (nicht überraschend) mit No such container beschwert.

Wenn Sie EndpointID anstelle des Containernamens/der Container-ID gemeint haben, habe ich das nicht versucht (aber beim nächsten Mal), weil das nicht das ist, was die --help vorgeschlagen haben.

@keithbentrup - Das {endpoint-name} im obigen Befehl ist im Grunde das container-id/name in der Ausgabe vom folgenden Befehl:

$deminem: docker network inspect e60b9386b9e2 wobei e60b9386b9e2 die Netzwerk-ID ist.

[
    {
        "Name": "project-name-master_default",
        "Id": "e60b9386b9e20f5222513bd6166f6d8e3224e72e906e2b07376e88ba79d87b26",
        "Created": "2020-04-02T18:48:29.2694181Z",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": true,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {
            "d435c36e882ec91dff780c55c0399c52b14096baea402647eaff2f1593602df9": {
                **"Name": "project-name-master_monitoring_1"**,
                "EndpointID": "7838e98efd8be4cabccc778707efadbb6194cbd73dc907f0129ee8b9119e4349",
                "MacAddress": "02:42:ac:12:00:0e",
                "IPv4Address": "172.18.0.14/16",
                "IPv6Address": ""
            }
        },
        "Options": {},
        "Labels": {
            "com.docker.compose.network": "default",
            "com.docker.compose.project": "project-name",
            "com.docker.compose.version": "1.25.4"
        }
    }
]

Hinweis: Wie fett hervorgehoben. "Name": "project-name-master_monitoring_1" .

Hatte es gerade mit

docker --version
Docker version 19.03.12-ce, build 48a66213fe
uname -a
Linux jotunheim 5.8.5-arch1-1 #1 SMP PREEMPT Thu, 27 Aug 2020 18:53:02 +0000 x86_64 GNU/Linux

auf Arch. Neustart des Dienstes hat geholfen.