one more thing - I'm doing something similar and I've found it necessary to 
use wait_for: to determine that port 22 actually went down before I wait 
for it to come up again.  I've also used wait_for_conection: to wait for it 
to come all the way back before I proceed.

On Thursday, August 16, 2018 at 3:14:56 PM UTC-4, Patrick Hunt wrote:
>
> I have the following playbook snippet
>
> ---
>
>
> - hosts: collector
>   become: true
>   become_method: su
>   become_user: root
>
>
>   tasks:
>
>
>   - name: restart server, if kernel updated
>     command: reboot
>     async: 1
>     poll: 0
>     ignore_errors: true
>     notify:
>       - wait for server to restart
>
>
>   handlers:
>   - name: wait for server to restart
>     wait_for:
>       host: "{{ ansible_default_ipv4.address }}"
>       port: 22
>       state: started
>       delay: 25
>       timeout: 300
>     become: false
>     delegate_to: localhost
>
>
> ...
>
>
>
> This is really part of a much larger maintenance playbook.  My problem is 
> that in our Test environment (RHEL 6 & 7) this succeeds, in our Dev 
> environment (CentOS 7) this fails.  When the play fails ansible will 
> connect and gather facts, when the play to restart is executed it will 
> state that the server is unreachable, however the task has been executed 
> and the server *is* restarted if you check the actual VM.  It seems that 
> the execution of the tasks completes before ansible is able to recognize 
> this fact, so it never gets to the point where it waits for the server to 
> restart and fails as unreachable instead.
>
> The ansible.cfg files are identical.  The inventory (hosts) files do not 
> have any additional variables/connection information other than hostnames 
> and groups defined.
>
> In the dev environment the playbook is executed as root, and in the Test 
> environment the playbook is executed as a user.
>
> Both environments are running ansible 2.6.2
>
> The dev environment functioned properly for a year or more until about 2-3 
> months ago when this restart task began to fail.
>
> Any ideas?
>
>
> Thanks, 
> Patrick
>

-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/e3dd9b44-c3d7-4676-9e5e-7f38be8ce188%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to