"No more loopback devices" error connecting to Docker daemon

[mcelligott]

I'm running the new Drone 0.4 (github.com/drone/drone/tree/0.4.0) which uses the rancher image to run docker in docker. My servers all run CentOS, while I hear that most/all other users are running Ubuntu and have not run into any issues. However, when I try to connect to the docker daemon, I get the following output, preventing the docker command from executing its intent:

time="2015-10-07T01:52:21.291793869Z" level=error msg="There are no more loopback devices available." 
time="2015-10-07T01:52:21.291869335Z" level=fatal msg="Error starting daemon: error initializing graphdriver: loopback mounting failed" 
Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

[ibuildthecloud]

This is because CentOS uses device mapper. That graph driver isn't very friendly to Docker in Docker. What happens in that on start it creates 2 loop back devices. When the container dies those don't get freed. So usually after 4 times you are out of devices.

On CentOS I think the most practical option is to use the vfs graph driver. It is slow and takes up a lot of disk space, but it doesn't crash :)

Basically if docker in docker is a must, CentOS is not a good option.

[bradrydzewski]

@mcelligott you can switch storage drivers in the .drone.yml file. Check out the Docker plugin documentation at http://addons.drone.io/docker/ and try using vfs in the storage_driver section as @ibuildthecloud suggests

@ibuildthecloud thanks for the explanation.

[ibuildthecloud]

Just wanted to throw out there that CentOS 7.2 when released will support overlayfs and then you won't see these issues.

[metal3d]

Having the issue, I just want to say that CentOS or RHEL are recomanded OS to launch OpenShift, and that many enterprises make use of RHEL or CentOS for kubernetes. I'm in that case, we want to give a chance to "drone" to be our CI/CD robot...

I'm using CentOS 7.2 and using overlayfs, so the driver to set is "overlay" now and not "vfs". Without that option in .drone.yml, the problem persists.

I can confirm that storage_driver: overlay is fast, and working as it does.