I'm trying to use Ansible to copy then untar software to a group of
'worker' machines. The Playbook is like this:
Devel or master branch? Try devel if you’re on master… let us know regardless.
Also, what OS are you running Ansible from?
This was on master, I just tried it on devel with the same effect -
although now it's failing with a socket.timout() (even with the
timeout on the 'ansible-playbook' command line increased to 30
seconds).
Hmmm. I'm running Ansible from a CentOS 5.7 machine - the 'worker'
machine is CentOS 6.2. I wonder if that's part of the problem... Will
try running Ansible from a newer machine.
There is some timeout code in execution that attempted to reuse the SSH timeout. This code is obviously undesirable on devel. master shouldn’t have hung though, first I’ve heard of that.
(possibly related – but curious anyway – python2.6 is pretty much required now, did you get py26 from EPEL?)
I discovered untar can throw some errors if your clocks are out of sync. I fixed it by redirecting stderr & stdout to /dev/null. But the timeout is a more likely cause…
command module eats out/err though, so it should never mess with the module returning or cause it to time out.
right?
Yes, you’re right… I was thinking of the work I did on the tar/untar work which was not using the command module and I hadn’t originally eaten the output.
> I discovered untar can throw some errors if your clocks are out of sync. I
> fixed it by redirecting stderr & stdout to /dev/null. But the timeout is a
> more likely cause..
That's interesting. I changed the action from this:
action: command tar -zxvf $worker/$java -C $worker
to this:
action: shell tar -zxvf $worker/$java -C $worker &> /dev/null
And it completes successfully. Is this just an issue when calling
'tar'? (note: I am using python 2.6 and the required dependencies from
EPEL).
Should not be the case.