compose: 1.5.0-rc2: Compose does not remove the network during rm

$ docker-compose --x-networking up -d
Creating network "counter" with driver "bridge"
Creating counter_web_1
Creating counter_mongo_1

$ docker-compose --x-networking stop
Stopping counter_mongo_1 ... done
Stopping counter_web_1 ... done

$ docker-compose --x-networking rm
Going to remove counter_mongo_1, counter_web_1
Are you sure? [yN] y
Removing counter_mongo_1 ... done
Removing counter_web_1 ... done

$ docker network ls
NETWORK ID          NAME                DRIVER
d84962a207f8        counter             bridge
f60408bc3b3b        bridge              bridge
13a612e10bd7        none                null
517effa88694        host                host

After, rm I still have a network created with the project name I would expect this to be removed

NOTE: This also causes an issue with Swarm that I will raise another issue for

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 16

Most upvoted comments

@dnephin

Is there any risk in leaving the network around?

I ran into errors like this:

Creating network "build11637" with driver "None"
failed to parse pool request for address space "LocalDefault" pool "" subpool "": could not find an available predefined network

I had several networks, each for every build left behind on our CI:

$ docker network ls | grep build
97c9fc99f9b5        build11590          bridge              
654e6c387d38        build11594          bridge              
5690c355e1fc        build11611          bridge              
83b1bf58a404        build11575          bridge              
d8a136713417        build11585          bridge              
ede77e84a10c        build11589          bridge              
4a8133a4bf52        build11563          bridge              
daf61484b71d        build11582          bridge              
cc9bc2d50565        build11613          bridge              
ebb7269c7a86        build11614          bridge              
90a2a868d521        build11579          bridge              
da13ed3d4f7b        build11576          bridge              
423e754545e7        build11570          bridge              
4f2e16b15487        build11591          bridge              
d9cd16ea5058        build11610          bridge              
0fb0a31b520f        build11616          bridge              
bbb35a3cbcc9        build11574          bridge              
d5b4d9cff806        build11593          bridge              
b014e86360ed        build11629          bridge              
2e14f3ee0cf2        build11631          bridge              
25c20171f9be        build11615          bridge              
6b3c9b172d6f        build11580          bridge              
2ba2519ee2f4        build11588          bridge              
9e16a476de94        build11612          bridge              
c0c2569fbd87        build11630          bridge              
67630ee308a6        build11573          bridge              
6f65f17c9f31        build11581          bridge              
834588ba0f49        build11572          bridge              
0a9baa340e4b        build11625          bridge   

I could only create new networks, after deleting old ones.

@dnephin I don’t think putting this in down would be the right solution

Engine already has flags in docker rm for handling volumes etc…

Usage:  docker rm [OPTIONS] CONTAINER [CONTAINER...]

Remove one or more containers

  -f, --force=false      Force the removal of a running container (uses SIGKILL)
  --help=false           Print usage
  -l, --link=false       Remove the specified link
  -v, --volumes=false    Remove the volumes associated with the container

Compose seems to be following this convention

Remove stopped service containers.

Usage: rm [options] [SERVICE...]

Options:
    -f, --force   Don't ask to confirm removal
    -v            Remove volumes associated with containers

As we create a network per project, I think it’s ok that we delete it too. It’s also safe to do this by default, as there is no risk of losing data (unlike deleting a volume)

Proposal Something like this would work. This would match my expection, that as a user, when I issue a “rm” it removes the containers and the network that was created for the project.

Remove stopped service containers.

Usage: rm [options] [SERVICE...]

Options:
    -f, --force              Don't ask to confirm removal
    -v                       Remove volumes associated with containers
    -n, --network=true       Remove the network associated with the project

If the users want’s to keep the network around for whatever reason, they can docker-compose rm -n

Networks had remained from previous starts, so the question here is if there could be a way to automagically remove redundant networks that are up there for whatever reason, but not used.

@ain

At least for development, you can just remove all networks, like so:

docker network rm $(docker network ls -q)

Docker should complain about predefined and in-use networks…

Error response from daemon: bridge is a pre-defined network and cannot be removed
Error response from daemon: host is a pre-defined network and cannot be removed
Error response from daemon: none is a pre-defined network and cannot be removed
Error response from daemon: network phd_default has active endpoints
Error response from daemon: network testphd_default has active endpoints
Error response from daemon: network wigdets2tests_default has active endpoints

My above-listed problem was eventually unrelated to docker-compose down, the removal works:

      01 docker-compose down
Stopping 20160523100010_web_1 ... done
      01 Stopping 20160523100010_db_1 ...
Stopping 20160523100010_db_1 ... done
      01 
      01 Removing 20160523100010_web_1 ...

      01 Removing 20160523100010_web_1 ... done
      01 

      01 Removing 20160523100010_db_1 ... done
      01 
      01 Removing network 20160523100010_default

Networks had remained from previous starts, so the question here is if there could be a way to automagically remove redundant networks that are up there for whatever reason, but not used.

I still have this issue. docker-compose down does not fix it. I have 31 networks all with unique names. I run compose with a new name that does not match any of the 31 networks but get the “could not find an available predefined network” error. Deleting the excess networks fixes it. I used @nenko-tabakov script that I am just running periodically.

It’s fairly reproducible with a CI environment where new builds happen often.

Hey guys, I have the same problem using docker-compose for testing. I ended up with 27 networks before docker-compose failed to start.

Here is a sample script for removing them:

for i in $( docker network ls | grep build | cut -f1 -d ’ ’ ); do docker network rm $i done

Just replace “build” with proper name.