Moby: Incapaz de remover a rede "tem endpoints ativos"

Este problema parece ser muito intermitente e não acontece com muita frequência.

@ rmb938 tivemos alguns problemas com endpoints pendentes e isso foi resolvido via # 17191. RC2 deve ter uma correção para isso (ou o mestre mais recente). Para testadores RC1 (muito obrigado), podemos precisar de uma solução alternativa adicional para limpar os estados antes de iniciar o RC2. vamos atualizar com documentos adequados.

Incrível. Obrigado.

@mavenugo Acabei de reproduzir isso no 1.10.0:

parece que # 17191 não foi uma solução completa ...

Você tem uma solução alternativa? Mesmo o salto do daemon do docker não parece resolver as coisas.

(e deixe-me saber se eu puder obter mais informações de depuração, ainda está reproduzindo em minha máquina)

Eu também reproduzi isso na versão 1.10.3 e cheguei aqui via google procurando por uma solução. Não consigo forçar a desconexão dos endpoints ativos porque nenhum dos contêineres listados por docker network inspect ainda existe.

Por fim, tive que recriar meu contêiner cônsul e reiniciar o docker daemon.

ping @mavenugo deseja que este problema seja reaberto ou prefere um novo caso tenha uma causa raiz diferente?

Esclarecimento, 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

Deixe-me reabrir isso para investigação

Madhu, atribuiu você, mas sinta-se à vontade para reatribuir, ou apontar para a solução alternativa relacionada, se ela já estiver lá: sorria:

@keithbentrup @brendandburns obrigado por levantar o problema. Algumas perguntas

1. Você está usando algum driver de rede multi-host (como driver Overlay)? Você pode compartilhar a saída de docker network ls .
2. Se você não usar o driver multi-host, pode compartilhar o arquivo /var/lib/docker/network/files/local-kv.db (por meio de algum site de compartilhamento de arquivos) e qual network você está tentando remover? E como a rede foi criada originalmente?

PARA SUA INFORMAÇÃO. para um driver de rede de vários hosts, o docker mantém os pontos de extremidade de uma rede em todo o cluster no KV-Store. Portanto, se algum host nesse cluster ainda tiver um endpoint ativo nessa rede, veremos esse erro e essa é uma condição esperada.

@thaJeztah PTAL meu comentário acima e com base no cenário, isso não precisa ser um bug. posso manter esse problema em aberto, se isso ajudar.

@mavenugo Sim, estou usando o driver overlay via docker-compose com um host swarm gerenciando 2 nós.

Quando eu docker network inspect a rede em cada nó individual, 1 nó tinha 1 contêiner listado que não existia mais e, portanto, não podia ser removido por docker rm -fv usando o nome ou id do contêiner.

@keithbentrup Este é um caso de endpoint obsoleto. Por acaso você tem o log de erros quando aquele contêiner que foi removido originalmente (que deixou o terminal neste estado)?
BTW, se o contêiner for removido, mas o endpoint ainda for visto, então é possível forçar a desconexão do endpoint usando docker network disconnect -f {network} {endpoint-name} . Você pode obter o nome do terminal no comando docker network inspect {network} .

@brendandburns pode ajudar a responder a https://github.com/docker/docker/issues/17217#issuecomment -195739573?

@mavenugo desculpe a demora. Não estou usando a rede docker multi-host afaik. É um único nó raspberry pi e eu não fiz nada além de instalar o docker via hypriot.

Aqui está a saída que você solicitou ( network é a rede que não consigo excluir)

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

O arquivo kv está anexado, tive que nomeá-lo .txt para contornar os filtros do github, mas é o arquivo binário.

local-kv.db.txt

Criei a rede por meio de chamadas de API diretas (dockerode)

Isso funcionou (criar e excluir) inúmeras vezes, acho que neste caso, I docker rm -f <container-id> mas não tenho certeza, posso ter desligado e religado a máquina ...

Espero que ajude.
--brendan

@mavenugo Se por docker network disconnect -f {network} {endpoint-name} você quer dizer docker network disconnect [OPTIONS] NETWORK CONTAINER por docker network disconnect --help , eu tentei isso, mas ele reclamou (não surpreendentemente) com No such container .

Se você quis dizer EndpointID vez do nome / id do contêiner, não tentei fazer isso (mas tentarei da próxima vez) porque não é isso que --help sugeriu.

@keithbentrup eu quis dizer a opção -f que está disponível na v1.10.x. A opção Force também considera o nome do terminal de outros nós no cluster. Portanto, minhas instruções anteriores funcionarão bem com a opção -f se você estiver usando o docker v1.10.x.

@brendandburns, obrigado pela informação e é bastante útil para restringir o problema. Há uma referência obsoleta ao ponto de extremidade que está causando esse problema. A referência obsoleta é provavelmente causada pelo ciclo de energia quando os nós de extremidade estavam sendo limpos. vamos resolver esse problema de inconsistência em 1.11.

@mavenugo feliz por ter ajudado. Nesse ínterim, se eu acabar com esse arquivo, as coisas ainda funcionarão?

obrigado
--brendan

@brendandburns sim. por favor, vá em frente. vai funcionar bem para você.

@mavenugo Acho que você me entendeu mal. Eu estava usando a opção -f (verificada em meu histórico de shell) na v1.10.x, mas com a id do contêiner (não a id do endpoint) b / c é o que a ajuda sugere (o contêiner não o endpoint). Se ele pretende funcionar com o id do contêiner ou com o id do endpoint, então é um bug b / c certamente não se desconecta com o id do contêiner e a opção -f quando o contêiner não existe mais.

Consegui recriar uma condição ao tentar remover docker_gwbridge que pode aliviar um pouco a confusão.
Quando usei o cliente docker apontando para um gerenciador de enxame, tive esta saída:

~/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

Primeiro tentei remover o contêiner pelo nome do contêiner (não mostrado), depois pela id e, em seguida, pela id do terminal do contêiner. Nenhum teve sucesso. Em seguida, conectei-me ao host docker e usei o cliente docker local para emitir comandos por meio do soquete Docker Unix:

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) Observe a saída de swarm vs cliente docker direto: swarm refere-se a contêineres; docker refere-se a endpoints. Isso provavelmente deve ser consistente.
2) A única opção bem-sucedida foi fornecer um nome de endpoint (não o nome ou id do container ou id do endpoint). O --help deve esclarecer que entradas ou várias entradas devem ser aceitáveis.
3) Não testei o nome do endpoint com swarm, então não sei se teria funcionado.

@keithbentrup isso está correto. como sugeri anteriormente. os docker network disconnect -f {network} {endpoint-name} ... pls usam o nome do ponto de extremidade. Podemos melhorar isso para oferecer suporte a endpoint-id também. Mas eu queria confirmar que, usando a opção forçar, você conseguiu fazer algum progresso.

@mavenugo mas o que você sugere não é o que a ajuda diz. além disso, falta a consistência da maioria dos cmds onde id / nome são intercambiáveis.

a menos que outros encontrem este tópico, outros irão repetir o mesmo problema, então antes de adicionar suporte para endpoint-id, corrija o --help .

@keithbentrup vamos consertar --help e a funcionalidade.

Acabei de reproduzir esse problema com o docker v1.11.2 enquanto tentava docker-compose down .
Uma tentativa anterior de executar docker-compose down fechou a rede app_front.

$ 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": {}                                                                                 
    }                                                                                                
]                                                                                                    

informação do docker

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                                                                             

Eu tenho alguns problemas ao tentar desconectar pontos de extremidade de sobreposição de enxame,

Resposta de erro do daemon: rede es-swarm-overlay possui endpoints ativos

@ rmb938 por favor diga o que há de errado? pode haver outro problema com essas questões?

@mavenugo

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

Isso funcionou para mim.

Posso ter o mesmo problema com docker 1.13.0 .

Já que ninguém neste tópico deu um exemplo do que eu fiz, vou postar.

Para completo, este é o erro que o inicia. Pode ser porque eu tenho codekitchen/dinghy-http-proxy:2.5.0 que escuta na porta 80.

$ 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.

E tentando derrubar tudo:

$ 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

E como eu matei a rede:

$ 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 tem uma solução válida. No entanto, minha equipe tem um arquivo docker-compose com cerca de 20 contêineres. Então, encontrei outra solução.

Eu gostaria de acrescentar que você também pode reiniciar o daemon do docker (por exemplo, systemctl restart docker em centos) e então os links entre a rede e os contêineres desaparecerão. Você pode docker system prune -f com sucesso.

@mdotson @nicolaiskogheim abra um novo exemplar; embora a mensagem de erro seja a mesma, o problema original discutido aqui foi corrigido. Você só vê isso ao usar o docker compose? Nesse caso, também pode ser um problema na ordem em que o docker compose executa as ações.

@thaJeztah Somente com docker-compose. Eu fiz isso ocorrer apenas uma vez, quando minha caixa Jenkins ficou sem memória e eu mal consegui matar os contêineres do docker. Talvez não houvesse memória suficiente para alocar para remover os links entre os contêineres e a rede?

Não tenho certeza, mas de qualquer forma, acho que a maioria das pessoas google uma mensagem de erro e chegará aqui procurando alguns comandos para copiar e colar para corrigir o problema.

Eu tive o mesmo problema que @nicolaiskogheim e @mdotson , meu contêiner influxdb ficou sem memória e tornou-se insalubre. Não consegui remover, parar ou remover (consegui remover com o modo forçado).
Depois disso, tentei reiniciar o docker com docker-compose :

# 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.

do que tentou excluir a rede:

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

e então tentei a solução @nicolaiskogheim :

# 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

A reinicialização do serviço docker corrigiu o problema para mim.

sudo service docker restart

docker network rm <network name>

Estou tendo o mesmo problema ao tentar remover uma pilha:

> 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

Eu primeiro criei a pilha assim:

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

Estou usando esta versão:

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

Felizmente, sudo service docker restart corrige, mas ainda não é o comportamento ideal.

Encontrado em 17.07.0-ce, a abordagem disconnect não funcionou, então reiniciei o docker e execute rm novamente com sucesso.

Também deparei com isso com um aglomerado de enxame de 17.06 ce; ficando sem opções além de reinicializar.

sudo service docker restart se livra dele para mim no ubuntu, me permitindo implantar e iniciar meus contêineres novamente.

Também funciona se um dos contêineres se recusar a morrer (acontece mais do que eu esperava). Irritante, pois me faz interromper todos os serviços por causa de um contêiner malicioso.

Tendo esse problema também em 17.09.0-ce. Reabra isso!

Isso estava acontecendo muito comigo em um ambiente de pouca memória. Veja se adicionar memória vai torná-lo melhor, meus processos param normalmente agora.

@tomholub Não, a memória não é o problema. Mas reiniciei o serviço docker, então eu poderia remover a rede.

Ainda tendo esse problema de vez em quando ao tentar parar e remover o contêiner de trabalho ativo. (Docker para Mac versão 17.09.0-ce-mac35 (19611) Canal: estável 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

Geralmente vai embora se eu esperar uma quantidade aleatória de segundos. Mas ainda está lá.

POR FALAR NISSO. Para mim, aconteceu durante docker-compose down --volumes --remove-órfãos

ainda vendo essas "redes órfãs", você pode reabrir @ rmb938 @thaJeztah

Resposta de erro do daemon: rede abcd_default id 3f2f1a6cb1cee2d82f2e2e59d10a099834a12b18eb7e3e48d6482d758bd93617 tem endpoints ativos

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

a única maneira de podá-los parece ser reiniciar o motor

Boa sorte hoje

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

Isso ainda pode ser reproduzido em Docker version 18.06.1-ce, build e68fc7a
Parece que mesmo quando os contêineres de um arquivo de composição são removidos, seus pontos de extremidade às vezes não são removidos, o que às vezes pode acontecer em caso de perda de energia, portanto, a composição falha ao iniciar ou remover completamente.

Quando nenhum comando funcionar, faça
sudo service docker restart
seu problema será resolvido

Ou sudo reboot -f . Funciona 100%.

Eu tive um problema semelhante hoje. o que fiz foi executar "docker container ls -a" e vi que poucos contêineres ainda em execução estavam utilizando a rede que eu havia lançado via docker stack. Então, manualmente, quando matei esses contêineres, consegui excluir a rede

Acredito que acabei de encontrar o problema que @danwdart mencionou aqui . Estou em Docker version 18.09.2, build 6247962 e executei docker-compose -f $PATH_TO_MY_CONFIG down e recebi o seguinte erro:

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

Na verdade, deixei a bateria do meu laptop acabar na noite passada, o que raramente faço, e depois de reiniciar o docker, fui capaz de executar o mesmo comando de composição "para baixo" com sucesso.

Isso pode ser óbvio para alguns, mas não era para mim, apenas pensei em compartilhar.

Eu precisava apenas executar docker-compose rm - docker-compose down é o que eu normalmente faço e ps -a não mostrou nenhum contêiner, então isso realmente me fez tropeçar até que executei o rm cmd . Pensei em compartilhar.

Acabo com o mesmo problema, pois a rede não conseguiu retirar com todas as acctions, notando ajudou. minha versão é Docker versão 18.09.6, compilação 481bc77

Para corrigir, reiniciei os serviços do docker. por "sudo service docker restart" depois disso consigo remover com "docker network rm {network}"

@danwdart Outra razão para isso é quando há contêineres pendurados. para removê-los, use o comando docker-compose down --remove-orphans que deve resolver o problema.

Olá de 2019, @mavenugo , gostaria de transmitir meus sinceros agradecimentos por ter a solução para este problema em 2016.

Isso ainda é um problema depois de mais de quatro anos. Existe alguma maneira mais simples de desconectar todos os contêineres de todas as redes às quais estão conectados do que um script de shell de mais de 10 linhas? FWIW isso parece funcionar:

#!/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

Resumindo:

1. Configure uma armadilha para remover o espaço de trabalho na saída.
2. Crie o espaço de trabalho.
3. Para cada contêiner:
   
   
   
   1. Para cada rede, o contêiner está associado:
      
      
      
      
      
      1. Tente se desconectar.
      
      
      
      2. Se a desconexão falhar porque já não está conectado à rede, ignore o erro (infelizmente parece ser aleatório se "o" faz parte da mensagem de erro). Caso contrário, falhe.
      
      
      
   
   

Uma combinação da solução @mavenugo e

Outro obrigado @mavenugo aqui de 2020

@mavenugo Se por docker network disconnect -f {network} {endpoint-name} você quer dizer docker network disconnect [OPTIONS] NETWORK CONTAINER por docker network disconnect --help , eu tentei isso, mas ele reclamou (não surpreendentemente) com No such container .

Se você quis dizer EndpointID vez do nome / id do contêiner, não tentei fazer isso (mas tentarei da próxima vez) porque não é isso que --help sugeriu.

@keithbentrup - O {endpoint-name} no comando acima é basicamente o container-id/name na saída do comando abaixo:

$deminem: docker network inspect e60b9386b9e2 onde e60b9386b9e2 é o id da rede.

[
    {
        "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"
        }
    }
]

Nota: Conforme destacado em negrito. "Name": "project-name-master_monitoring_1" .

Acabou de ficar com

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

em Arch. O reinício do serviço ajudou.