Control socket connect(...): Connection refused

4,540 views
Skip to first unread message

Traun Leyden

unread,
Jun 10, 2015, 2:48:03 PM6/10/15
to ansible...@googlegroups.com

I'm running ansible on Ubuntu 14.04.2 LTS running OpenSSH_6.6.1p1 inside of a Docker container with a CoreOS host, and running this command as root:

ansible key_tleyden -i inventory -m ping -u centos -vvvv

and seeing this error: 

ec2-52-152-154-133.compute-1.amazonaws.com | FAILED => SSH Error: debug2: set_control_persist_exit_time: schedule exit in 60 seconds
    while connecting to 10.152.151.154:22

After quite a lot of digging (I wish ansible gave a clearer error message here), it seemed to be related to SSH ControlPersist, so I tried running this command (also as root):

ssh -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=$CP cen...@10.119.181.141

and with that I get the error:

Control socket connect(/root/.ansible/cp/ansible-ssh-10.119.181.141-22-centos): Connection refused

I can see the domain socket here:

srw------- 1 root root    0 Jun 10 18:11 ansible-ssh-ec2-54-157-151-133.compute-1.amazonaws.com-22-centos

but am unclear on why ssh can't seem to use it. 

If I change my ansible.cfg to disable the ControlPersist settings via:

[ssh_connection]
ssh_args =

Then the ansible errors completely go away.



Traun Leyden

unread,
Jun 10, 2015, 3:01:48 PM6/10/15
to ansible...@googlegroups.com

So far this is looking like a really obscure CoreOS issue.  I tried against Ubuntu running inside a Docker container on an Ubuntu host, and couldn't reproduce this.  Sorry for the noise.  (but any insight would still be welcome)

Nel Roque

unread,
Jan 12, 2016, 8:29:16 AM1/12/16
to Ansible Project
Please check: 

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1262287

In a nutshell, the latest ssh versions and overlayfs don't play well together, after much trouble I just configured the ControlPath ssh option to point to a tmpfs path inside the docker container and voilá. 

I'm using the castawaylabs/semaphore docker image on CoreOS stable (835.9.0)

Cheers
Message has been deleted

Brian Coca

unread,
Jan 12, 2016, 8:37:55 AM1/12/16
to Ansible Project
@Nel, thanks for figuring this one out, this seems like a pretty nasty bug.


--
Brian Coca

WhileLoop

unread,
Dec 7, 2016, 11:35:30 PM12/7/16
to Ansible Project
I can confirm changing the the control path to a tmpfs location fixed the problem for me. In my case I used /dev.
Reply all
Reply to author
Forward
0 new messages