agregar && sleep 1

shell: /sbin/shutdown -r now "Ansible system package upgraded" && sleep 1

como solución temporal para evitar que la conexión se cierre antes de que Ansible pueda "recoger" los archivos temporales y cerrar la conexión.

Solo como información, esto está documentado en https://support.ansible.com/hc/en-us/articles/201958037-Reboot-a-server-and-wait-for-it-to-come-back aunque no se mantiene en este repositorio de documentos y no aparece en docs.ansible.com

@bcoca Se agregó como dijiste, pero aún se encontró con el mismo error. Tengo que usar ignore_errors: true para omitir ese error.

• nombre: reinicia el sistema cuando se actualiza el paquete
  comando: / sbin / shutdown -r ahora "Paquete de sistema Ansible actualizado" && sleep 1
  cuando: latest_state.changed
  ignore_errors: verdadero
  etiquetas: upgrade_packages_all

Error:
fatal: [96.119.246.13]: ¡FALLÓ! => {"cambiado": falso, "fallido": verdadero, "module_stderr": "", "module_stdout": "El demonio PolicyKit desconectado del bus.r \ nYa no somos un agente de autenticación registrado.r \ n", "msg": "FALLO DEL MÓDULO", "analizado": falso}

Tuve el mismo problema con 2.0.0.2, esta solución me ayudó:

- name: Wait for server come back
  wait_for: >
    host="{{ inventory_hostname }}"
    port=22
    delay=15
    timeout=60
  delegate_to: localhost

@ gvenka008c :

Quizás quieras probar:

shell: sleep 2 && /sbin/shutdown -r now

@andyhky funcionó !! :) ¡Gracias! La solución final en Ansible 2.1 que funciona es la siguiente

- name: Restart server
  become: yes
  shell: sleep 2 && /sbin/shutdown -r now "Ansible system package upgraded"


- name: waiting 30 secs for server to come back
  local_action: wait_for host={{ ansible_default_ipv4.address }} port=22 state=started delay=30 timeout=60
  become: false

@sayantandas, ¿la solución sigue funcionando para ti? Estoy usando ansible 2.1.1.0 y obtengo lo siguiente:
UNREACHABLE! => {"changed": false, "msg": "SSH Error: data could not be sent to the remote host. Make sure this host can be reached over ssh", "unreachable": true}

Encontré esta respuesta que me resuelve el problema: http://stackoverflow.com/a/39174307

- name: Restart server
  become: yes
  shell: sleep 2 && /sbin/shutdown -r now "Ansible system package upgraded"
  async: 1
  poll: 0

El local_action sigue al reinicio de shell siempre se salta por mí. Un vistazo a la salida -vvv solo indica que se omitió debido a un condicional. ¿Alguien más está experimentando esto? Puedo abrir un nuevo ticket si aparentemente no está relacionado.

Puedo confirmar que esto se rompió por completo en 2.1 en nuestra instalación. Lo hicimos funcionar en 1.9 en la forma "1.9", actualizamos Ansible a 2.1, modificamos la tarea a la forma "2.1" y se rompe todo el tiempo.

Esta solución funciona un poco con mi instalación. Sin embargo, local_action espera todo el tiempo de espera cada vez: mi host puede reiniciarse en ~ 30 segundos, pero si configuro el tiempo de espera wait_for en 3600, Ansible esperará una hora antes de continuar con el libro de jugadas. .. Como algunos reinicios pueden ser más largos que otros (actualizaciones), realmente necesito tener un tiempo de espera alto, pero no puedo permitirme perder 15 minutos para que mis anfitriones regresen (ocurre 5 veces en mi libro de jugadas principal :()

Después de un poco de prueba y error con varias soluciones publicadas para varias versiones, lo siguiente me funciona en 2.1.2 con una máquina virtual invitada Ubuntu 16.04 y un host OS X usando Vagrant (1.8.6) y VirtualBox (5.1.8).

- name: "Reboot if required"
  shell: sleep 2 && shutdown -r now 'Reboot required' removes=/var/run/reboot-required
  become: true
  async: 1
  poll: 0
  ignore_errors: true

- name: "Wait for reboot"
  local_action: wait_for host={{ ansible_default_ipv4.address }} port=22 delay=10 state=started
  become: false

@Furiml : No estoy seguro de si esto se aplica a lo que está tratando de hacer, pero esta segunda tarea sondeará cada 10 segundos (predeterminado) después de un retraso de 10 segundos para ver si el puerto 22 en la máquina invitada está abierto antes de continuar, es decir, ganó no se toma el valor total del tiempo de espera asignado.

Una actualización de los documentos y / o el artículo de soporte para usar el formato YAML completo preferido para las tareas también sería bueno. Esto funciona para mi:

    - name: reboot nodes
      shell: sleep 2 && shutdown -r now "Ansible reboot"
      async: 1
      poll: 0
      ignore_errors: true

    - name: wait for server to come back
      local_action: wait_for
      args:
        host: "{{ inventory_hostname }}"
        port: 22
        state: started
        delay: 30
        timeout: 300

Escribí algo más para probar esto. En lugar de esperar a que un host esté activo, quiero esperar a que esté inactivo.

    - name: "Wait for the machine to be down"
      local_action: wait_for
      args:
        host={{target}}
        port=22
        state=stopped
        delay=1
        timeout=3600
      become: false

Si entendí bien, esto sondeará el puerto 22 de mi objetivo cada segundo y solo continuará si está cerrado. Apago la máquina yo mismo, pero Ansible está atascado durante 5 minutos ahora :(

@martineg ¡ eso funciona muy bien! Ahora está incluido en el rol de Galaxy jmcvetta.debian-upgrade-reboot .

En ansible 2.2 esto no reinicia mi computadora. Simplemente dice que se inició el trabajo y luego espera el puerto 22. ¡Pero el nodo no se reinicia!

Tengo el mismo problema que @sashgorokhov en Ubuntu 16.04 / ansible 2.2.1.0.

Solo dice "OK" y no se reinicia.
ok: [IP] => { "ansible_job_id": "575686775528.32762", "changed": false, "finished": 0, "results_file": "/root/.ansible_async/575686775528.32762", "started": 1 }

@NoahO tal vez este pequeño fragmento de código pueda ayudarte:

tasks:
    - shell: shutdown -r now

Esto simplemente reinicia el nodo sin esperarlo (en mi caso, realmente no necesito esperar a que se reinicie)

@sashgorokhov, desafortunadamente, lo necesito para reiniciar, lo

Intento que esto funcione en servidores Centos 7.3 desde la estación de trabajo F25 con Ansible 2.2.1, pero parece que no funciona. ¿Alguna solución?
En este punto, considero seriamente crear un rol separado para la tarea que necesito ejecutar después de reiniciar y llamar a los 2 roles desde un script de shell con una suspensión lo suficientemente larga entre ellos o, si quiero ser elegante, puedo agregar un ssh-keyscan también para asegurarse de que el servidor esté funcionando ... Pero prefiero confiar en Ansible, ya sabe, ya que es una herramienta de automatización real;)

EDITAR:
Ok, fui un completo idiota y un poco cerca de la medianoche aquí, no tengo miedo de admitirlo ... INVENTARIO INCORRECTO FFS. ¡Trabajos! Lo siento...

Tener el mismo problema. ¿Alguna actualización sobre este asunto? Parece que muchas personas se enfrentan a este problema

Esto sigue siendo un problema (Mac versión 2.3.0.0), el destino es una instancia de Fedora en AWS. Ninguna de las soluciones anteriores funcionó para mí (no se produjo un error, pero tampoco lo reinicié), así que hice lo siguiente (donde delayed_reboot es solo un script de shell, suspensión y reinicio):

- copy:
    src: files/delayed_reboot
    dest: /tmp/delayed_reboot
    owner: root
    group: root
    mode: 0700

- name: Restart machine
  shell: nohup /tmp/delayed_reboot &
  async: 1
  poll: 0
  ignore_errors: true
  become: true
  become_method: sudo
  when: new_kernel.changed or new_kernel_headers.changed

- name: Wait for machine to restart
  local_action:
    module: wait_for
      host={{ inventory_hostname }}
      port=22
      delay=20
      timeout=300
      state=started
  become: false
  when: new_kernel.changed or new_kernel_headers.changed

TIPO DE PROBLEMA

• Informe de error

NOMBRE DEL COMPONENTE

Conexión compartida

VERSION ANSIBLE

ansible 2.3.0.0
  config file = /Users/ebalduf/PD-git/LabOnDemand/ansible.cfg
  configured module search path = Default w/o overrides
  python version = 2.7.13 (default, Dec 18 2016, 07:03:39) [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]

CONFIGURACIÓN

grep '^[^#]' ansible.cfg
[defaults]
host_key_checking = False
timeout = 15
[privilege_escalation]
[paramiko_connection]
[ssh_connection]
control_path = %(directory)s/%%h-%%r
[persistent_connection]
[accelerate]
[selinux]
[colors]
[diff]

SO / MEDIO AMBIENTE

Anfitrión Ansible: macOS Sierra 10.12.4
destino: instancia de Fedora 25 en AWS.

RESUMEN

PASOS PARA REPRODUCIR

- name: install python and deps for ansible modules
  raw: dnf install -y python2 python2-dnf libselinux-python

- name: gather facts
  setup:

- name: Install new Kernel
  dnf:
    name: https://kojipkgs.fedoraproject.org//packages/kernel/4.9.13/201.fc25/x86_64/kernel-core-4.9.13-201.fc25.x86_64.rpm
  register: new_kernel

- name: Install new Kernel headers
  dnf:
    name: https://kojipkgs.fedoraproject.org//packages/kernel/4.9.13/201.fc25/x86_64/kernel-headers-4.9.13-201.fc25.x86_64.rpm
  register: new_kernel_headers

- name: Restart machine
  command: reboot
  async: 1
  poll: 0
  ignore_errors: true
  become: true
  become_method: sudo
  when: new_kernel.changed or new_kernel_headers.changed

- name: Wait for machine to restart
  local_action:
    module: wait_for
      host={{ inventory_hostname }}
      port=22
      delay=20
      timeout=300
      state=started
  become: false
  when: new_kernel.changed or new_kernel_headers.changed

- También puede pegar enlaces a gist.github.com para archivos más grandes

RESULTADOS PREVISTOS

El objetivo debe reiniciarse correctamente y ansible continuar con el libro de jugadas.

RESULTADOS ACTUALES

Vea el resultado a continuación con -vvv

Using module file /usr/local/lib/python2.7/site-packages/ansible/modules/commands/command.py
<34.209.10.206> ESTABLISH SSH CONNECTION FOR USER: fedora
<34.209.10.206> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=fedora -o ConnectTimeout=15 -o ControlPath=/Users/ebalduf/.ansible/cp/%h-%r 34.209.10.206 '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
<34.209.10.206> (0, '/home/fedora\n', '')
<34.209.10.206> ESTABLISH SSH CONNECTION FOR USER: fedora
<34.209.10.206> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=fedora -o ConnectTimeout=15 -o ControlPath=/Users/ebalduf/.ansible/cp/%h-%r 34.209.10.206 '/bin/sh -c '"'"'( umask 77 && mkdir -p "` echo /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672 `" && echo ansible-tmp-1493487050.48-176600574616672="` echo /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672 `" ) && sleep 0'"'"''
<34.209.10.206> (0, 'ansible-tmp-1493487050.48-176600574616672=/home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672\n', '')
<34.209.10.206> PUT /var/folders/sd/5jlrqcms5qg3bjc0g5mp5r1r0000gn/T/tmpeV4QiT TO /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/command.py
<34.209.10.206> SSH: EXEC sftp -b - -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=fedora -o ConnectTimeout=15 -o ControlPath=/Users/ebalduf/.ansible/cp/%h-%r '[34.209.10.206]'
<34.209.10.206> (0, 'sftp> put /var/folders/sd/5jlrqcms5qg3bjc0g5mp5r1r0000gn/T/tmpeV4QiT /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/command.py\n', '')
<34.209.10.206> ESTABLISH SSH CONNECTION FOR USER: fedora
<34.209.10.206> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=fedora -o ConnectTimeout=15 -o ControlPath=/Users/ebalduf/.ansible/cp/%h-%r 34.209.10.206 '/bin/sh -c '"'"'chmod u+x /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/ /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/command.py && sleep 0'"'"''
<34.209.10.206> (0, '', '')
<34.209.10.206> ESTABLISH SSH CONNECTION FOR USER: fedora
<34.209.10.206> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=fedora -o ConnectTimeout=15 -o ControlPath=/Users/ebalduf/.ansible/cp/%h-%r -tt 34.209.10.206 '/bin/sh -c '"'"'sudo -H -S -n -u root /bin/sh -c '"'"'"'"'"'"'"'"'echo BECOME-SUCCESS-jplodcrkimvnywjebybiuhwijxipglmt; /usr/bin/python /home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/command.py; rm -rf "/home/fedora/.ansible/tmp/ansible-tmp-1493487050.48-176600574616672/" > /dev/null 2>&1'"'"'"'"'"'"'"'"' && sleep 0'"'"''
<34.209.10.206> (255, '', 'Shared connection to 34.209.10.206 closed.\r\n')
fatal: [34.209.10.206]: UNREACHABLE! => {
    "changed": false,
    "unreachable": true
}

MSG:

Failed to connect to the host via ssh: Shared connection to 34.209.10.206 closed.

¡Gracias @ebalduf por poner todo esto junto! También puedo confirmar que también estoy enfrentando un problema idéntico con ansible 2.2.1 con MacOS / CentOS como hosts ansible y CentOS7 como host de destino. ¡Sería bueno si se pudiera priorizar este error!

El siguiente código funciona para mí
Versión Ansible - 2.3
Servidor: Ubuntu 16.04.2 LTS

Sistema de destino - RHEL 7.3

- name: restart server
  become: yes
  shell: sleep 2 && /sbin/shutdown -r now "RedHat system package upgraded"
  async: 1
  poll: 0

- name: waiting 60 secs for server to come back
  become: false
  local_action: wait_for host={{ ansible_default_ipv4.address }} port=22 state=started delay=60 timeout=120

La solución proporcionada por @sayantandas también funciona para nosotros.

Versión de Ansible: 2.3.0.0
Versión del servidor: CentOS Linux versión 7.3.1611
Sistema de destino: CentOS Linux versión 7.3.1611

La solución proporcionada por @sayantandas también funciona para mí

Versión de Ansible: 2.3.0.0
Versión del servidor: RHEL 7.3
Sistema de destino: RHEL 7.3

Gracias

Ansible 2.3, Centos7, a continuación, es lo que utilicé después de hacer algo que actualiza el kernel, evita la 'espera a que arranque el host' si el host no se está reiniciando.

  - name: Check for reboot hint.
    shell: LAST_KERNEL=$(rpm -q --last kernel | perl -pe 's/^kernel-(\S+).*/$1/' | head -1);CURRENT_KERNEL=$(uname -r); if [ $LAST_KERNEL != $CURRENT_KERNEL ]; then echo 'reboot'; else echo 'no'; fi
    ignore_errors: true
    register: reboot_hint

  - name: Rebooting ...
    shell: sleep 2 && /usr/sbin/reboot
    async: 1
    poll: 0
    ignore_errors: true
    when: reboot_hint.stdout.find("reboot") != -1

  - name: Wait for host to boot
    become: false
    local_action: wait_for
    args:
      host: "{{ inventory_hostname }}"
      port: 22
      state: started
      delay: 30
      timeout: 180
    when: reboot_hint.stdout.find("reboot") != -1

No se puede reiniciar correctamente, incluso con controles de cordura.

Ansible 2.2.2.0

Libro de jugadas de ejemplo para Ubuntu 16.04 LTS

---
- name: Refresh apt cache
  apt:
    update_cache: yes

- name: Update all packages
  apt:
    upgrade: dist

- name: Rebooting server
  shell: >
    sleep 2 &&
    /sbin/shutdown -r now "Ansible system package upgraded"
  async: 1
  poll: 0
  ignore_errors: true

- name: Wait for host to boot
  become: false
  local_action: wait_for
  args:
    host: "{{ inventory_hostname }}"
    port: 22
    state: started
    delay: 30
    timeout: 200

- name: Sanity check
  shell: ps -ef | grep sshd | grep `whoami` | awk '{print \"kill -9\", $2}' | sh
  async: 1
  poll: 0
  ignore_errors: true

- name: Remove useless packages from the cache
  apt:
    autoclean: yes

- name: Remove dependencies that are no longer required
  apt:
    autoremove: yes

Resultado

TASK [apt-refresh : Remove useless packages from the cache] ********************
fatal: [xxxx]: FAILED! => {"changed": false, "failed": true, "module_stderr": "OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016\r\ndebug1: Reading configuration data /etc/ssh/ssh_config\r\ndebug1: /etc/ssh/ssh_config line 19: Applying options for *\r\ndebug1: auto-mux: Trying existing master\r\ndebug1: mux_client_request_session: master session id: 2\r\nShared connection to xxxx closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n  File \"/tmp/ansible_MJ_gDg/ansible_module_apt.py\", line 903, in <module>\r\n    main()\r\n  File \"/tmp/ansible_MJ_gDg/ansible_module_apt.py\", line 855, in main\r\n    for package in packages:\r\nTypeError: 'NoneType' object is not iterable\r\n", "msg": "MODULE FAILURE"}

ansible.cfg

[defaults]
inventory = hosts
host_key_checking = False
remote_user = ubuntu
private_key_file = id_rsa
retry_files_enabled = False

[ssh_connection]
ssh_args = -C -o ControlMaster=auto -o ControlPersist=60s
control_path = /tmp/%%h-%%p-%%r

Tenía problemas similares. Agregué una tarea de 'pausa' durante 30 segundos entre el shell: apagar ahora -r y la tarea wait_for. Ahora las cosas funcionan constantemente. También tengo estos como controladores con listen, por lo que solo se ejecutan cuando es necesario.

Tuve problemas similares al intentar reiniciar nuestros hosts Ubuntu 16.04 con ansible configurado para usar python3. Tan pronto como instalé Python 2.7 en los hosts de Ubuntu 16.04 (apt-get install python-minimal) y configuré ansible para usarlo en el sistema remoto, el reinicio funcionó bien.
Siempre que usé "async" en mi tarea, exactamente no sucedió nada cuando ansible usó python3, ni siquiera cosas muy básicas como "echo test> / tmp / testfile".

Además: estoy usando ansible 2.3.1.0 instalado a través del paquete deb desde http://ppa.launchpad.net/ansible/ansible/ubuntu

Por lo tanto, hay un complemento de acción

Estamos trabajando en un nuevo complemento de acción de reinicio que realizará un reinicio, esperará a que la conexión comience a funcionar nuevamente y finalmente verifica si el sistema se reinició realmente.

cc @AnderEnder @gregswift @jarv @jhoekx
haga clic aquí para obtener ayuda con el bot

Sistema de destino - CentOS 7.4

- name: restart server
  become: yes
  shell: sleep 2 && /sbin/shutdown -r now "System reboot"
  #command: /usr/bin/systemd-run --on-active=10 /usr/bin/systemctl reboot
  async: 1
  poll: 0

- name: waiting 10 secs for server to come back
  become: false
  local_action: wait_for host={{ ansible_default_ipv4.address }} port={{ ansible_port }} state=started delay=10 timeout=120  

@peterwillcn IMO Es mejor que use wait_for_connection en lugar de wait_for , consulte: http://docs.ansible.com/ansible/latest/wait_for_connection_module.html

No solo es más fácil, también funciona sobre jumphosts o proxies, usando exactamente el mismo transporte que Ansible usa para el nodo de destino.

@dagwieers ¿cómo va el complemento de acción de reinicio?

Encontré un par de roles para encargarme de esto:

• https://galaxy.ansible.com/GROG/reboot/
• https://galaxy.ansible.com/pgkehle/restart/

@afeld ese papel se ve genial.

Entonces, mi problema con todos los ejemplos que he visto es que todo se basa en un tiempo de espera aleatorio antes de comenzar la encuesta para ver si el puerto ssh está disponible. Ahora, dado que los diferentes hosts requieren diferentes cantidades de tiempo para apagar los procesos según lo que estén haciendo, significa que debe establecer un retraso largo para atrapar al peor infractor o corre el riesgo de falsos positivos.

El nuevo wait_for_connection solo usa ping y otro factor de retardo aleatorio (ver arriba). De nuevo, existe un gran riesgo de falsos positivos (confirmado por el soporte de redhat).

La forma en que lo he hecho un poco más robusto es usando 2 tareas: la primera espera a que el puerto ssh esté ausente, esto comienza de inmediato y tiene una espera máxima de 15 minutos, sondeos cada segundo, esto debería ser suficiente tiempo para que los procesos del servidor se apaguen y significa que solo debe esperar a que se detengan los servicios regulares del sistema operativo.

El segundo ssh no se está ejecutando Inicia la tarea 2 - esperar el estado del puerto ssh - se inicia después de 1 min de retraso.

Tenga en cuenta que el puerto wait_for no depende de ssh, usa un socket de python para determinar si el puerto está activo

Andy

Enviado desde mi iPhone

El 12 de diciembre de 2017, a las 05:41, Shaun Smiley [email protected] escribió:

@afeld ese papel se ve genial.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

@akcrisp Y el problema con su implementación es que falla en cualquier cosa que no sea el caso de uso simple de conexión directa. El módulo wait_for_connection también solía hacer esto, pero falla para ssh_proxy u otras conexiones de transporte proxy, por lo que tuvimos que eliminarlo.

Puede configurar el tiempo de retardo por sistema / grupo u otras características, pero eso no es ideal.

¿De acuerdo, pero no está claro cómo se arregla esto sin? ¿Un dedo no determinista en el aire de demora aleatoria?

Enviado desde mi iPhone

El 12 de diciembre de 2017, a las 16:20, Dag Wieers [email protected] escribió:

@akcrisp Y el problema con su implementación es que falla en cualquier cosa que no sea el caso de uso simple de conexión directa. El módulo wait_for_connection también solía hacer esto, pero falla para ssh_proxy u otras conexiones de transporte proxy, por lo que tuvimos que eliminarlo.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

¿No es posible agregar un cheque ssh a wait_for connection
Además, agregue grace_timeout algo así como en los grupos de ajuste de escala automático de AWS: espere un poco más después de que se establezca la "conexión"

esto funcionó bien para mí:
_ansible: 2.4.1.0
Ubuntu: 16.04.3 LTS
Linux 4.4.0-98-genérico_

  - name: reboot server
    become: yes
    shell: sleep 2 && /sbin/shutdown -r now "System reboot"
    async: 1
    poll: 0

  - name: Wait for restart
    local_action: wait_for port=22 host="{{ ansible_ssh_host | default(inventory_hostname) }}"  search_regex=OpenSSH delay=60

  - name: continue running script after reboot
    shell: 'sh /home/ubuntu/my_script.sh'

Esto funcionó para mí en Ansible 2.4.2.0 y Ubuntu 16.04 LTS en Azure

- hosts: all
  become: yes
  become_user: root
  pre_tasks:
    - name: Patching for Spectre and Meltdown followed by a reboot
      become: yes
      shell: nohup bash -c 'sleep 2 && apt -y update && apt -y upgrade && apt -y autoremove && reboot "System reboot"' &
      async: 1
      poll: 0

    - name: Wait for 3 minutes for server to come online
      become: false
      local_action: wait_for port=22 host={{ ansible_ssh_host | default(inventory_hostname) }} search_regex='OpenSSH' delay=180 timeout=300

Supongo que mi caso de uso fue mucho más complejo. Aquí está el mío escrito como controlador:

- name: Inform of reboot required
  listen: reboot machine
  debug:
    msg: "System {{ inventory_hostname }} needs to be rebooted for changes to take effect"

- name: Update GRUB to pick up changes to default config, if any
  command: update-grub2
  listen: reboot machine

  # Send the reboot command and let it run in the background
  # so we can disconnect...
- name: Send reboot command
  listen: reboot machine
  shell: '(sleep 5; shutdown -r now) &'

- name: Clear host errors
  listen: reboot machine
  meta: clear_host_errors
  failed_when: false

- name: Reset connection
  listen: reboot machine
  meta: reset_connection
  failed_when: false

- name: Wait for SSH to be available
  listen: reboot machine
  local_action: wait_for
  args:
    host: "{{ ansible_host }}"
    port: "{{ ansible_port | default('22') }}"
    delay: 60
    state: started

- name: Ansible ping
  listen: reboot machine
  local_action: ping
  register: result
  until: result.ping is defined and result.ping == 'pong'
  retries: 30
  delay: 10

- name: Run uptime
  listen: reboot machine
  command: uptime

  # LACP and spanning-tree take a bit of time to start working
- name: Ping default gateway
  listen: reboot machine
  command: "ping -c 1 {{ ansible_default_ipv4.gateway }}"
  register: result
  until: result.rc == 0
  retries: 30
  delay: 10

Aquí está mi solución (Ansible 2.4.2):

- name: restart machine
  shell: nohup sh -c '(sleep 5; shutdown -r now "Ansible restart") &' &>/dev/null
  become: yes

- name: wait for machine to restart
  wait_for_connection:
    delay: 60
    sleep: 5
    timeout: 300

esto funcionó para mí:

- name: restart the system
    shell: "sleep 5 & reboot"
    async: 1
    poll: 0

- name: wait for the system to reboot
    wait_for_connection:
      connect_timeout: 20
      sleep: 5
      delay: 5 
      timeout: 60

Todas estas soluciones son interesantes, pero la verdadera solución será

Estamos trabajando en un nuevo complemento de acción de reinicio que realizará un reinicio, esperará a que la conexión comience a funcionar nuevamente y finalmente verifica si el sistema se reinició realmente.

¿Correcto? (de https://github.com/ansible/ansible/issues/14413#issuecomment-330523110)

Confirmado.

deseando que llegue

Estoy interesado en saber si algún módulo de reinicio admitirá varios tipos de Unix más allá de Linux. Es decir, aix / Solaris, etc., ¿supongo que funciona con Windows?

El punto que hice con mi ejemplo y la mayoría parece haberlo pasado por alto, es que simplemente teniendo un tiempo de espera para el puerto 22, es completamente posible obtener un falso positivo, si un host tarda más en cerrar los procesos, es decir, piense en una base de datos grande. - que el factor de retraso, entonces es posible que no se haya reiniciado realmente - probado y demostrado que esto puede suceder - por lo tanto, mi prueba para garantizar que ssh esté ausente primero.

Andy

Enviado desde mi iPhone

El 28 de febrero de 2018, a las 15:04, Dag Wieers [email protected] escribió:

Confirmado.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

@akcrisp Esa es la intención. La discusión estaba vinculada aquí antes: https://github.com/ansible/ansible/issues/16186

---
- hosts: all
- name: restart the system
    shell: "sleep 5 & reboot"
    async: 1
    poll: 0

- name: wait for the system to reboot
    wait_for_connection:
      connect_timeout: 20
      sleep: 5
      delay: 5
      timeout: 60

ansible-playbook test.yaml
¡ERROR! Error de sintaxis al cargar YAML.
Los valores de mapeo no están permitidos en este contexto.

El error parece haber estado en '/etc/ansible/test.yaml': línea 4, columna 10, pero puede
estar en otra parte del archivo dependiendo del problema de sintaxis exacto.

La línea ofensiva parece ser:

• nombre: reinicia el sistema
  shell: "dormir 5 y reiniciar"
  ^ aquí

ayuda por favor ;-)

---
- hosts: all
- name: restart the system
  shell: "sleep 5 & reboot"
     async: 1
     poll: 0

- name: wait for the system to reboot
  wait_for_connection:
       connect_timeout: 20
       sleep: 5
       delay: 5
       timeout: 60

Prueba esto.

Dolor - Ojalá la gente leyera lo que he hecho. Todo el que esté esperando el tiempo de espera se arriesga a un falso positivo. Una aplicación solo tardará un tiempo en apagarse y pensará que ssh está activo después de reiniciar. Lo he probado.

Es mucho mejor verificar que ssh esté ausente primero, que no depende de shh, usa una conexión de socket de Python

Enviado desde mi iPhone

El 16 de abril de 2018, a las 09:21, Ben Abineri [email protected] escribió:

---

• hosts: todos

• nombre: reinicia el sistema
  shell: "dormir 5 y reiniciar"
  asincrónico: 1
  encuesta: 0

• nombre: espere a que el sistema se reinicie
  espera_para_conexión:
  connect_timeout: 20
  dormir: 5
  retraso: 5
  tiempo de espera: 60
  Prueba esto.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o silencia el hilo.

Tienes razón, mi comentario no fue un respaldo del diseño, solo quería demostrar el formato correcto.

Este error relacionado parece ser una causa de que la tarea de reinicio asíncrono no se ejecute como @pyroxde se señaló anteriormente

37941

Así que ahora tenemos un complemento de acción reiniciar y win_reboot para reiniciar los servidores Unix y Windows. Si tiene algún problema con la implementación existente, no dude en abrir un nuevo problema con detalles específicos.