Error running provisioning: Unable to verify the Docker daemon is listening

I recently upgraded to Rancher 0.59.1 and i am now having trouble creating new hosts in AWS. I completely reinstalled docker (1.10.3) and a new rancher still with no luck. Everytime i try to install a new host, after a few minutes i get this error in the rancher web console:

Error running provisioning: Unable to verify the Docker daemon is listening: Maximum number of retries (5) exceeded

I am also running the rancher server on RHEL 7 in AWS, and deploying hosts in RHEL as well (can’t use ubuntu).

Any thoughts as to why i can’t deploy new hosts anymore?

I tried deploying a host with plain Ubuntu and it worked fine, however RHEL 7.2 on AWS does not. Seems like something operating-system specific.

Based on what you are describing, it looks like you are launching hosts from the UI. If so, these hosts are just calling a docker-machine to launch instances in AWS.

Docker-machine takes care of launching the instance and installing docker.

The error you are providing is a failure to communicate with docker. Since the installation of docker and verification happens using docker-machine this seems to be an issue with either the aws docker-machine driver or with RHEL 7 on AWS, with docker-machine.

Have you tried running docker-machine command outside of Rancher to see if it works there? If it works, then please let us know and we can look further into it. If not, I would recommend filing an issue with docker-machine.

Ok so i was able to successfully run with docker-machine to create a red hat instance inside AWS. Including the command below, it works and i can connect to the ec2 instance. Not sure why rancher has a problem with creating the new host, i’d prefer to work through the rancher UI.

Docker-Machine command that works:

docker-machine -D create
–driver amazonec2
–amazonec2-access-key XXX
–amazonec2-secret-key XXX
–amazonec2-vpc-id vpc-XXX
–amazonec2-ami ami-2051294a
–amazonec2-ssh-user ec2-user
–amazonec2-subnet-id subnet-XXX
–amazonec2-security-group XXX

@pinkdevelops - Thanks for bringing this to our attention. We could reproduce this issue. It is actually a bug in docker machine, and you can track the bug here -