Waiting for servers after reboot

1,110 views
Skip to first unread message

Anand Buddhdev

unread,
Jan 17, 2014, 3:25:47 PM1/17/14
to ansible...@googlegroups.com
Hi ansible users,

I have a playbook to reboot all my servers serially, using the "serial: 1" option in the playbook. I have the tasks:

- command: /sbin/reboot
- local_action: wait_for host={{inventory_hostname}} port=22 state=stopped

- local_action: wait_for host={{inventory_hostname}} port=22

However, some of my managed servers are not directly reachable from my laptop, so I usually connect to them via a bastion host. This means that the port 22 test will fail for them.

I thought about using the ping module instead, which should just do an SSH ping to a host. However, the ping module times out after a while when the underlying ssh connection times out, so I can't make it wait long enough for the server to finish rebooting.

Does anyone have any ideas or suggestions on how to work around this?

Anand

Michael DeHaan

unread,
Jan 17, 2014, 3:38:41 PM1/17/14
to ansible...@googlegroups.com
"However, some of my managed servers are not directly reachable from my laptop, so I usually connect to them via a bastion host. This means that the port 22 test will fail for them."

You could consider running Ansible from the bastion host, versus using an SSH jumphost which I infer you are using above.

The ping module doesn't ICMP ping, BTW, it's a basic Ansible connectivity test.




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.



--
Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

Anand Buddhdev

unread,
Jan 17, 2014, 3:59:01 PM1/17/14
to ansible...@googlegroups.com
On Friday, 17 January 2014 21:38:41 UTC+1, Michael DeHaan wrote:

You could consider running Ansible from the bastion host, versus using an SSH jumphost which I infer you are using above.

Yes, by bastion, I meant an SSH jump host.
 
The ping module doesn't ICMP ping, BTW, it's a basic Ansible connectivity test.

Yes, I realise that the ansible ping module is not ICMP, but an SSH connection. The SSH jump host doesn't have ansible installed, and I don't have root access on it. I can of course install ansible in a virtualenv, but I was hoping for some cleverer way of detecting host down/up from within a playbook run from my laptop. I suppose my use-case is an outlier, so I'll try to see what I can do on the jump host. 

Michael DeHaan

unread,
Jan 17, 2014, 4:47:43 PM1/17/14
to ansible...@googlegroups.com
Yeah, I'm open to the idea of a ping module action_plugin that takes a 'mode=icmp' (default ssh).

You could also just do a "shell: ping" (making sure to ping just once) and register the return code.




--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Michael DeHaan

unread,
Jan 17, 2014, 4:47:52 PM1/17/14
to ansible...@googlegroups.com
i.e. local_action: ping ...


zperry

unread,
Jul 12, 2014, 2:41:58 PM7/12/14
to ansible...@googlegroups.com

I am running into a similar situation and have been thinking about using the shell: ping approach too. But what I came up in the following didn't seem to do the trick. Would appreciate a hint:

---
- name: ping a remote host many times
  local_action: shell ping -v {{ inventory_hostname }}
  register: result
  until: result.stdout.rc == '0'
  retries: 5
  delay: 5

I can also confirm that the typical approach using wait_for as published, e.g. by ansible support, works only with one-hop, anytime ssh jump-host (more than one hop) is used, the approach fails.

--Zack

zperry

unread,
Jul 12, 2014, 2:51:49 PM7/12/14
to ansible...@googlegroups.com

Quick correction and follow-up:

I should have been more careful when cut-n-paste.

The task include file should be

---
- name: ping a remote host many times
  local_action: shell ping -v {{ inventory_hostname }}
  register: result

  until: result.rc == '0'
  retries: 5
  delay: 5

Note on the until: line, I should have been written it as result.rc =='0'.  When I said it didn't work, I meant that at the end of my test, I saw:

msg: Task failed as maximum retries was encountered

FATAL: all hosts have already failed -- aborting

That's just as ugly :(  I don't have an idea how to make a "normal" play termination yet.  Any hints appreciated.

-- Zack


On Saturday, July 12, 2014 11:41:58 AM UTC-7, zperry wrote:

I am running into a similar situation and have been thinking about using the shell: ping approach too. But what I came up in the following didn't seem to do the trick. Would appreciate a hint:

---
- name: ping a remote host many times
  local_action: shell ping -v {{ inventory_hostname }}
  register: result
  until: result.stdout.rc == '0'
  retries: 5
  delay: 5

I can also confirm that the typical approach using wait_for as published, e.g. by ansible support, works only with one-hop, anytime ssh jump-host (more than one hop) is used, the approach fails.

--Zack

[...]
Reply all
Reply to author
Forward
0 new messages