Ansible: Ansible se cuelga para siempre mientras ejecuta el libro de jugadas sin información sobre lo que está sucediendo

Puede habilitar el modo de depuración para obtener más información de la que -v* le brinda. Para hacer esto, simplemente exporte ANSIBLE_DEBUG=1 para habilitarlo.

Probablemente necesitemos más información para intentar ayudarlo con esto, lo que con suerte proporcionarán los registros de depuración. Parece que muchos hosts parecen mucho para conectarse simultáneamente, ¿se está ejecutando en paralelo o en bloques de hosts?

need_info

Hmm, ¿a qué estás colocando las horquillas? Llegar a muchos hosts a la vez puede consumir muchos recursos; vale la pena comprobar también / var / log / messages.

Es posible que desee probar wait_for_connection como una forma de probar que todos sus hosts están disponibles. Es bueno, ya que conoce el tipo de conexión, por lo que funciona incluso si tiene un inventario mixto de, por ejemplo, Windows y Linux.

Hola, está conectando un máximo de 10 hosts al mismo tiempo, esta es la configuración:

[defaults]
host_key_checking = False
timeout = 20
retry_files_save_path = /home/ansible/retry/
# Do not put more jobs here, or ssh will fail
# Anything more than 10 kills this poor server
forks = 10
remote_user = root
log_path=/var/log/ansible.log

[ssh_connection]
retries=3
pipelining=True

Me las arreglé para encontrar un "bloque de hosts" que contiene el que probablemente está causando este bloqueo, así que ahora estoy eliminando más y más hosts de ese archivo temporal con la esperanza de identificar el que causa esto.

Mi suposición aproximada es que tal vez se cuelga de la consulta de DNS. ¿Es posible que uno de estos hosts no exista y el servidor DNS mal configurado haga que la consulta tarde una eternidad? No tengo idea, pero estoy bastante seguro de que no hay información detallada disponible ni siquiera en el registro de depuración, intentaré proporcionarla pronto. Veo algunas líneas de depuración, luego veo verde ok: [nombre de host] y luego nada para siempre, ni una sola línea de depuración o verbosa, simplemente se cuelga.

Después de mucho tiempo de depurar y probar los servidores uno por uno, descubrí cuál estaba causando esto. Su DNS está bien, responde y puedo ssh allí, pero hay algún problema:

 12502 1506511086.24143: starting run
 12502 1506511086.42742: Loading CacheModule 'memory' from /usr/lib/python2.7/site-packages/ansible/plugins/cache/memory.py
 12502 1506511086.63981: Loading CallbackModule 'default' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/default.py
 12502 1506511086.64073: Loading CallbackModule 'actionable' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/actionable.py (found_in_cache=False, class_only=True)
 12502 1506511086.64109: Loading CallbackModule 'context_demo' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/context_demo.py (found_in_cache=False, class_only=True)
 12502 1506511086.64146: Loading CallbackModule 'debug' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/debug.py (found_in_cache=False, class_only=True)
 12502 1506511086.64166: Loading CallbackModule 'default' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/default.py (found_in_cache=False, class_only=True)
 12502 1506511086.64226: Loading CallbackModule 'dense' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/dense.py (found_in_cache=False, class_only=True)
 12502 1506511086.67297: Loading CallbackModule 'foreman' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/foreman.py (found_in_cache=False, class_only=True)
 12502 1506511086.68313: Loading CallbackModule 'hipchat' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/hipchat.py (found_in_cache=False, class_only=True)
 12502 1506511086.68376: Loading CallbackModule 'jabber' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/jabber.py (found_in_cache=False, class_only=True)
 12502 1506511086.68409: Loading CallbackModule 'json' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/json.py (found_in_cache=False, class_only=True)
 12502 1506511086.68476: Loading CallbackModule 'junit' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/junit.py (found_in_cache=False, class_only=True)
 12502 1506511086.68511: Loading CallbackModule 'log_plays' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/log_plays.py (found_in_cache=False, class_only=True)
 12502 1506511086.68598: Loading CallbackModule 'logentries' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/logentries.py (found_in_cache=False, class_only=True)
 12502 1506511086.68675: Loading CallbackModule 'logstash' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/logstash.py (found_in_cache=False, class_only=True)
 12502 1506511086.68789: Loading CallbackModule 'mail' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/mail.py (found_in_cache=False, class_only=True)
 12502 1506511086.68823: Loading CallbackModule 'minimal' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/minimal.py (found_in_cache=False, class_only=True)
 12502 1506511086.68855: Loading CallbackModule 'oneline' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/oneline.py (found_in_cache=False, class_only=True)
 12502 1506511086.68892: Loading CallbackModule 'osx_say' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/osx_say.py (found_in_cache=False, class_only=True)
 12502 1506511086.68932: Loading CallbackModule 'profile_tasks' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/profile_tasks.py (found_in_cache=False, class_only=True)
 12502 1506511086.68973: Loading CallbackModule 'selective' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/selective.py (found_in_cache=False, class_only=True)
 12502 1506511086.69006: Loading CallbackModule 'skippy' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/skippy.py (found_in_cache=False, class_only=True)
 12502 1506511086.69063: Loading CallbackModule 'slack' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/slack.py (found_in_cache=False, class_only=True)
 12502 1506511086.69186: Loading CallbackModule 'syslog_json' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/syslog_json.py (found_in_cache=False, class_only=True)
 12502 1506511086.69221: Loading CallbackModule 'timer' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/timer.py (found_in_cache=False, class_only=True)
 12502 1506511086.69256: Loading CallbackModule 'tree' from /usr/lib/python2.7/site-packages/ansible/plugins/callback/tree.py (found_in_cache=False, class_only=True)
 12502 1506511086.69296: in VariableManager get_vars()
 12502 1506511086.71899: Loading FilterModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/core.py
 12502 1506511086.71980: Loading FilterModule 'ipaddr' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/ipaddr.py
 12502 1506511086.72396: Loading FilterModule 'json_query' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/json_query.py
 12502 1506511086.72433: Loading FilterModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/mathstuff.py
 12502 1506511086.72655: Loading TestModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/test/core.py
 12502 1506511086.72845: Loading TestModule 'files' from /usr/lib/python2.7/site-packages/ansible/plugins/test/files.py
 12502 1506511086.72880: Loading TestModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/test/mathstuff.py
 12502 1506511086.73542: done with get_vars()
 12502 1506511086.73603: in VariableManager get_vars()
 12502 1506511086.73665: Loading FilterModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/core.py (found_in_cache=True, class_only=False)
 12502 1506511086.73686: Loading FilterModule 'ipaddr' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/ipaddr.py (found_in_cache=True, class_only=False)
 12502 1506511086.73702: Loading FilterModule 'json_query' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/json_query.py (found_in_cache=True, class_only=False)
 12502 1506511086.73717: Loading FilterModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/mathstuff.py (found_in_cache=True, class_only=False)
 12502 1506511086.73765: Loading TestModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/test/core.py (found_in_cache=True, class_only=False)
 12502 1506511086.73783: Loading TestModule 'files' from /usr/lib/python2.7/site-packages/ansible/plugins/test/files.py (found_in_cache=True, class_only=False)
 12502 1506511086.73799: Loading TestModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/test/mathstuff.py (found_in_cache=True, class_only=False)
 12502 1506511086.73921: done with get_vars()

PLAY [all:!ignored] **********************************************************************************************************************************************************************************************************************************
 12502 1506511086.81512: Loading StrategyModule 'linear' from /usr/lib/python2.7/site-packages/ansible/plugins/strategy/linear.py
 12502 1506511086.82241: getting the remaining hosts for this loop
 12502 1506511086.82263: done getting the remaining hosts for this loop
 12502 1506511086.82282: building list of next tasks for hosts
 12502 1506511086.82297: getting the next task for host in-terminal01.prod.domain.tld
 12502 1506511086.82315: done getting next task for host in-terminal01.prod.domain.tld
 12502 1506511086.82330:  ^ task is: TASK: Gathering Facts
 12502 1506511086.82345:  ^ state is: HOST STATE: block=0, task=0, rescue=0, always=0, run_state=ITERATING_SETUP, fail_state=FAILED_NONE, pending_setup=True, tasks child state? (None), rescue child state? (None), always child state? (None), did rescue? False, did start at task? False
 12502 1506511086.82360: done building task lists
 12502 1506511086.82376: counting tasks in each state of execution
 12502 1506511086.82390: done counting tasks in each state of execution:
        num_setups: 1
        num_tasks: 0
        num_rescue: 0
        num_always: 0
 12502 1506511086.82405: advancing hosts in ITERATING_SETUP
 12502 1506511086.82418: starting to advance hosts
 12502 1506511086.82432: getting the next task for host in-terminal01.prod.domain.tld
 12502 1506511086.82448: done getting next task for host in-terminal01.prod.domain.tld
 12502 1506511086.82462:  ^ task is: TASK: Gathering Facts
 12502 1506511086.82478:  ^ state is: HOST STATE: block=0, task=0, rescue=0, always=0, run_state=ITERATING_SETUP, fail_state=FAILED_NONE, pending_setup=True, tasks child state? (None), rescue child state? (None), always child state? (None), did rescue? False, did start at task? False
 12502 1506511086.82492: done advancing hosts to next task
 12502 1506511086.83078: getting variables
 12502 1506511086.83098: in VariableManager get_vars()
 12502 1506511086.83157: Loading FilterModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/core.py (found_in_cache=True, class_only=False)
 12502 1506511086.83176: Loading FilterModule 'ipaddr' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/ipaddr.py (found_in_cache=True, class_only=False)
 12502 1506511086.83193: Loading FilterModule 'json_query' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/json_query.py (found_in_cache=True, class_only=False)
 12502 1506511086.83209: Loading FilterModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/filter/mathstuff.py (found_in_cache=True, class_only=False)
 12502 1506511086.83247: Loading TestModule 'core' from /usr/lib/python2.7/site-packages/ansible/plugins/test/core.py (found_in_cache=True, class_only=False)
 12502 1506511086.83263: Loading TestModule 'files' from /usr/lib/python2.7/site-packages/ansible/plugins/test/files.py (found_in_cache=True, class_only=False)
 12502 1506511086.83281: Loading TestModule 'mathstuff' from /usr/lib/python2.7/site-packages/ansible/plugins/test/mathstuff.py (found_in_cache=True, class_only=False)
 12502 1506511086.83394: done with get_vars()
 12502 1506511086.83421: done getting variables
 12502 1506511086.83438: sending task start callback, copying the task so we can template it temporarily
 12502 1506511086.83453: done copying, going to template now
 12502 1506511086.83470: done templating
 12502 1506511086.83484: here goes the callback...

TASK [Gathering Facts] ********************************************************************************************************************************************************************************************************************************************************
 12502 1506511086.83515: sending task start callback
 12502 1506511086.83530: entering _queue_task() for in-terminal01.prod.domain.tld/setup
 12502 1506511086.83694: worker is 1 (out of 1 available)
 12502 1506511086.83772: exiting _queue_task() for in-terminal01.prod.domain.tld/setup
 12502 1506511086.83840: done queuing things up, now waiting for results queue to drain
 12502 1506511086.83859: waiting for pending results...
 12511 1506511086.84236: running TaskExecutor() for in-terminal01.prod.domain.tld/TASK: Gathering Facts
 12511 1506511086.84316: in run()
 12511 1506511086.84379: calling self._execute()
 12511 1506511086.85119: Loading Connection 'ssh' from /usr/lib/python2.7/site-packages/ansible/plugins/connection/ssh.py
 12511 1506511086.85207: Loading ShellModule 'csh' from /usr/lib/python2.7/site-packages/ansible/plugins/shell/csh.py
 12511 1506511086.85264: Loading ShellModule 'fish' from /usr/lib/python2.7/site-packages/ansible/plugins/shell/fish.py
 12511 1506511086.85346: Loading ShellModule 'powershell' from /usr/lib/python2.7/site-packages/ansible/plugins/shell/powershell.py
 12511 1506511086.85381: Loading ShellModule 'sh' from /usr/lib/python2.7/site-packages/ansible/plugins/shell/sh.py
 12511 1506511086.85423: Loading ShellModule 'sh' from /usr/lib/python2.7/site-packages/ansible/plugins/shell/sh.py (found_in_cache=True, class_only=False)
 12511 1506511086.85479: Loading ActionModule 'normal' from /usr/lib/python2.7/site-packages/ansible/plugins/action/normal.py
 12511 1506511086.85500: starting attempt loop
 12511 1506511086.85516: running the handler
 12511 1506511086.85572: ANSIBALLZ: Using lock for setup
 12511 1506511086.85589: ANSIBALLZ: Acquiring lock
 12511 1506511086.85606: ANSIBALLZ: Lock acquired: 29697296
 12511 1506511086.85624: ANSIBALLZ: Creating module
 12511 1506511087.15592: ANSIBALLZ: Writing module
 12511 1506511087.15653: ANSIBALLZ: Renaming module
 12511 1506511087.15678: ANSIBALLZ: Done creating module
 12511 1506511087.15765: _low_level_execute_command(): starting
 12511 1506511087.15786: _low_level_execute_command(): executing: /bin/sh -c '/usr/bin/python && sleep 0'
 12511 1506511087.16363: Sending initial data
 12511 1506511089.69186: Sent initial data (103646 bytes)
 12511 1506511089.69246: stderr chunk (state=3):
>>>mux_client_request_session: session request failed: Session open refused by peer
ControlSocket /home/ansible/.ansible/cp/170b9dc5f6 already exists, disabling multiplexing
<<<

Aquí cuelga para siempre. Reemplacé el dominio de esta empresa con "domain.tld", el nombre de dominio real es diferente.

Esto sigue siendo un error en Ansible, al menos en el sentido de que Ansible debería producir algún mensaje de ERROR detallado que le permita al usuario saber qué host está causando el bloqueo para que el host se pueda eliminar del archivo de inventario sin necesidad de una investigación compleja de qué salió mal.

También ejecutando un inventario grande (2400+), viendo errores similares y pasando por la misma solución de problemas prolongada con la esperanza de encontrar la verbosidad del registro que me indique una mejor dirección.

ansible 2.4.1.0
python version = 2.7.5 (default, May  3 2017, 07:55:04) [GCC 4.8.5 20150623 (Red Hat 4.8.5-14)]

Verlo llegar al final de un libro de jugadas y no recibir el futex y las llamadas de cierre. Desde el comienzo de un trabajo que muestra el problema:

21:39:26 stat("/var/lib/awx/projects/<job>/host_vars", 0x7ffd4ce0dfd0) = -1 ENOENT (No such file or directory)
21:39:26 stat("/var/lib/awx/.cache/facts/<host>", 0x7ffd4ce0dae0) = -1 ENOENT (No such file or directory)
21:39:26 stat("/var/lib/awx/.cache/facts/<host>", 0x7ffd4ce0dcf0) = -1 ENOENT (No such file or directory)
21:39:26 select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
21:39:26 select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
... infinite Timeout

De un trabajo exitoso:

21:39:39 stat("/var/lib/awx/projects/<job>/host_vars", 0x7ffd4ce0dfd0) = -1 ENOENT (No such file or directory)
21:39:39 stat("/var/lib/awx/.cache/facts/<host>", 0x7ffd4ce0dae0) = -1 ENOENT (No such file or directory)
21:39:39 stat("/var/lib/awx/.cache/facts/<host>", 0x7ffd4ce0dcf0) = -1 ENOENT (No such file or directory)
21:39:39 select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
21:39:39 select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
21:39:39 futex(0x7fb178001390, FUTEX_WAKE_PRIVATE, 1) = 1
21:39:39 futex(0x1e9d090, FUTEX_WAKE_PRIVATE, 1) = 1
21:39:39 futex(0x1e9d090, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
21:39:39 futex(0x1e9d090, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
21:39:39 futex(0x1e9d090, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
21:39:39 futex(0x1e9d090, FUTEX_WAIT_PRIVATE, 0, NULL) = 0
21:39:39 futex(0x7f15690, FUTEX_WAKE_PRIVATE, 1) = 1
21:39:39 futex(0x1e9d090, FUTEX_WAKE_PRIVATE, 1) = 1
21:39:39 futex(0x711f9e0, FUTEX_WAIT_PRIVATE, 0, NULL) = -1 EAGAIN (Resource temporarily unavailable)
21:39:39 close(7)                       = 0
... continues to close and wrap up

@benapetr / @jmighion, ¿cómo resolvieron el problema subyacente? Tratando de encontrar una solución cuando surgen problemas como este

Hay varias razones por las que esto puede suceder. Nunca dije que encontré una solución. En teoría, puede ejecutar el libro de jugadas a mano en un bucle en cada host por separado para averiguar cuál está causando problemas, y luego debe investigar este host.

Un buen ejemplo de problema que puede causar esto es el montaje NFS desconectado, que colgaría incluso el comando "df".

Lo siento, no recuerdo haber encontrado una solución. Creo que el nuestro estaba colgando de un dispositivo al que estábamos tratando de conectarnos, pero honestamente no puedo decirlo. Sin embargo, ya no estamos abordando el problema.

https://github.com/ansible/ansible/issues/30411#issuecomment -360766621

Un buen ejemplo de problema que puede causar esto es el montaje NFS desconectado, que colgaría incluso el comando "df".

Ese era exactamente mi problema. Ningún parámetro ansible.cfg (ni timeout fact_caching_timeout) me ayudó a interrumpir el proceso. Muchas gracias!
En mi opinión, esto debería resultar en un error / tiempo de espera en la máquina de control.

Tuve un problema similar, configuré pipelining de True a False , ejecuté el libro de jugadas (con éxito después de este cambio) y luego lo configuré de nuevo en True Las ejecuciones posteriores del libro de jugadas también funcionaron correctamente.

Editar: @benapetr : ¡Gracias! Este fue en realidad el problema subyacente. Se monta una carpeta sobre SSHFS a través de un túnel SSH inverso (para empujar desde la máquina de control ansible). Después de conectarse manualmente a través de SSH a la máquina de destino y desmontar umount -l ... el problema desapareció.

Parece que tengo un problema similar con ansible y un montaje nfs en el objetivo. lsof, df, ansible .. todo colgado.
Establecer la canalización en falso en ansible.cfg no ayudó.

@jeroenflvr : En mi caso, el montaje de sshfs se cuelga (también cuando se invoca el comando de montaje manualmente). Cambié al montaje CIFS / samba sobre el túnel inverso SSH y ahora funciona sin colgar. Esto parece estar parcialmente relacionado con fusibles pero no ansibles.

No importa si el bloqueo en el host de destino es causado por fusible, nfs o algo, sigue siendo un error de Ansible en la forma en que 1 host de destino no debería poder bloquear el juego completo para todos los demás hosts.

Debe haber algún tiempo de espera o vigilancia interna implementada que acabaría con el libro de jugadas por mal comportamiento y máquinas rotas. 1 máquina averiada de 5000 no debería estropear Ansible para las 5000 máquinas.

@benapetr sí, esto hay que

El mismo problema para mí.
Tengo seis hosts de MacOS y ejecuto:
ansible-playbook tcmacagents.yml -f 6
Se cuelga del primer paso "Recopilación de hechos". Siempre en el mismo host (tcmacagent5):
`` Tarea [Datos Gathering] `* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ok: [tcmacagent1]
ok: [tcmacagent2]
ok: [tcmacagent6]
ok: [tcmacagent3]
ok: [tcmacagent4]

strace:

```[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[pid 24072] wait4(24211, 0x7ffc608410a4, WNOHANG, NULL) = 0
[pid 24072] wait4(24211, 0x7ffc608410d4, WNOHANG, NULL) = 0
[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[pid 24072] wait4(24211, 0x7ffc608410a4, WNOHANG, NULL) = 0
[pid 24072] wait4(24211, 0x7ffc608410d4, WNOHANG, NULL) = 0
[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[pid 24072] wait4(24211, 0x7ffc608410a4, WNOHANG, NULL) = 0
[pid 24072] wait4(24211, 0x7ffc608410d4, WNOHANG, NULL) = 0
[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[pid 24072] wait4(24211, 0x7ffc608410a4, WNOHANG, NULL) = 0
[pid 24072] wait4(24211, 0x7ffc608410d4, WNOHANG, NULL) = 0
[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)
[pid 24072] wait4(24211, 0x7ffc608410a4, WNOHANG, NULL) = 0
[pid 24072] wait4(24211, 0x7ffc608410d4, WNOHANG, NULL) = 0
[pid 24072] select(0, NULL, NULL, NULL, {0, 1000}) = 0 (Timeout)

¿Cómo puedo solucionarlo? ¿Qué le pasa a mi tcmacagent5?

# ansible --version
ansible 2.5.0

Si es un soporte y no se puede usar (toque un archivo o algo) vuelva a montarlo. En mi situación especial, siempre revertí una máquina virtual a una instantánea con fines de prueba y el identificador de NFS no coincide con esta máquina virtual, por lo que está en estado obsoleto

También hemos experimentado que Ansible se cuelga sin ningún mensaje de error, al ejecutar libros de jugadas contra 23 hosts, con forks=25 . Usamos Ansible 2.2.3.0, pero tenemos el mismo problema con Ansible 2.5.3. Ejecutamos nuestros libros de jugadas desde macOS 10.12.6, usando Python 2.7.15. Con forks=5 no veo el problema. Tampoco vemos el problema al usar transport=paramiko (y forks=25 ).

Tenemos el mismo problema. Playbooks se cuelga aleatoriamente durante la reproducción sin mensajes de error. Una vez que presione ctrl + c, el libro de jugadas continúa.

Esto también es un problema para mí, ejecutar ansible 2.16.1. Creo que ocurre principalmente durante la etapa de recopilación de datos cuando 'df' se cuelga (en mi caso). debería haber un mecanismo para recopilar hechos con la opción de excluir algunas partes (?), ... solo un pensamiento.

Tengo el mismo problema, algún tipo de tiempo de espera (básicamente pausar el libro de jugadas sin error)
Estoy usando el complemento de conexión ansible de kubectl para conectar mis pods de kubernetes y ejecutar el libro de jugadas contra esos hosts (3 pods). Es muy lento, como tomar 8 segundos para ejecutar cada módulo en el host remoto y hacer una pausa en medio del libro de jugadas un poco extraño sin ningún error o masaje.

¿Cómo puede quedar sin resolver un problema tan grave durante tanto tiempo?

¿Nadie tiene tiempo para trabajar en una solución?

@pillarsdotnet : finalmente

Veo este problema sin montajes de red en absoluto. Solo instancias de AWS simples que ejecutan Ubuntu 18.

Ok, después de verificar en qué sesión ssh estaba atascado, descubrí que en mi caso estaba yum para siempre porque no se pudo conectar a los espejos. Por supuesto, cualquier otro proceso de suspensión puede / hará lo mismo. El verdadero problema a resolver son los tiempos de espera en general.

@strarsis , también puede simplemente usar un montaje suave en lugar de un montaje duro (lo que le dice que bloquee! en IO si falta el objetivo). Pero este no es el punto. como dice @tuxick , el problema es que no hay manejo de errores para los tiempos de espera remotos. Arreglar manualmente tiempos de espera triviales en el entorno circundante para que la automatización pueda administrarlo es ... ¿POR QUÉ UNO INCLUSO DISCUTA ESO?
(la parte "df" de la recopilación podría fallar legítimamente, o el módulo "yum" podría fallar ... incluso un sistema podría fallar si no podemos encontrar algo menos triste. pero lo que no puede ser es un truco de _todo ejecutar_ contra un env)

Sí, si no puedo encontrar una solución, voy a recomendar oficialmente que cambiemos de ansible a un sistema de automatización más maduro.

https://docs.ansible.com/ansible/2.5/user_guide/playbooks_async.html incluso usa yum como ejemplo. Esto no resuelve todos los problemas, pero ayudará en caso de que sepa que las cosas pueden "colgarse", como nfs mounts y yum.

@tuxick Entonces, en general, debería reemplazar esto:

- name: Something that might hang
  module:
    param: data
  option: value

con este:

- name: Something that might hang
  block:
    - module:
        param: data
      option: value
      async: '{{ async_timeout|default(1000) }}'
      register: 'something_that_might_hang'
    - async_status:
        jid: '{{ something_that_might_hang.ansible_job_id }}'
      register: '{{ something_that_might_hang_result }}'
      retries: '{{ async_retries|default(30) }}'
      until: 'something_that_might_hang_result is defined and
              "finished" in something_that_might_hang_result and
               something_that_might_hang_result.finished'
      when: 'something_that_might_hang.ansible_job_id is defined'

Me quedé con "async: 300" simple por ahora pero seguro, puede verse mejor :). Me pregunto si debería incorporarse algún tipo de tiempo de espera en los módulos que podrían sufrir este tipo de problemas. De todos modos, los únicos que vi continuar para siempre han sido nfs y yum.

La mayoría de los bloqueos que veo son con pip.

En realidad, el patrón anterior está fallando, con un error que indica que la cláusula when no se pudo evaluar porque la variable en la cláusula register no está definida.

(patrón actualizado ...)

Una forma sencilla de evitar bloqueos, siempre que pueda identificar las tareas potencialmente colgantes.

Reemplazar esto:

- name: Something that might hang
  module:
    param: data
  option: value

con este:

- name: Something that might hang
  module:
    param: data
  option: value
  async: '{{ async_timeout|default(1000) }}'
  poll: '{{ async_poll|default(10) }}'

Tengo que estar de acuerdo en que nos hemos enfrentado a este problema pocas veces cuando tenemos más de 1000 servidores en inventario y parece que hay clientes. Cada módulo debe tener un tiempo de espera que debe pasar al siguiente host o tarea si algo se atasca durante xx minutos. Cada vez que tenemos que recortar el número de hosts en el inventario y ejecutar trabajos una y otra vez. Para cuando llegamos al último conjunto, el problema está resuelto con un host incorrecto y no podemos averiguar qué salió mal.

Tengo el mismo problema con el hecho con ansible 2.5.1
Usé datos limitados collect_subset = network, que es suficiente para mí, ya que solo necesito información de ip, kernel y os para configurar mis group_vars, parece que está bien
pero parece que algunos módulos están usando lsof, como zypper, creo, tuve un libro de jugadas atascado que estaba atascado, mirando los procesos, descubra lsof -n -FpcuLRftkn0, después de matarlo, el libro de jugadas comienza a reanudarse :(

cuando se trata de actualizar una gran cantidad de servidores, es un verdadero problema

Así que estamos buscando algunas cosas que podrían ayudar, # 47684 agrega un nuevo evento para devoluciones de llamada para mostrar 'en qué host' se está iniciando una tarea, luego puede comparar con los hosts 'terminados' para averiguar cuál se colgó.

Otra línea de ataque es # 49398, que intenta lidiar con el principal sospechoso / culpable en la mayoría de los casos, consultando información de montaje, esto espera acelerar el proceso, rechazar los cheques bloqueados e informar con la información completa o la razón por la que no pudieron (tiempo de espera o error real).

Hola,

este problema también existe en ansible 2.6

ansible 2.6.11 config file = None configured module search path = [u'/home/pkolze/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules'] ansible python module location = /home/pkolze/.virtualenvs/ansible26/local/lib/python2.7/site-packages/ansible executable location = /home/pkolze/.virtualenvs/ansible26/bin/ansible python version = 2.7.13 (default, Sep 26 2018, 18:42:22) [GCC 6.3.0 20170516]

de mi lado, problema causado por oom:
[2507.235957] Sin memoria: Proceso de muerte 14022 (ansible-playboo) puntúa 393 o sacrifica a un niño
[2507.238181] Proceso muerto 14022 (ansible-playboo) total-vm: 408724kB, anon- rss: 175508kB , file- rss: 732kB

definitivamente no relacionado con ansible
mis 2 centavos

cuando ejecuto un comando con wait_for y timeout, el tiempo de espera no funciona si la conexión con el host está rota. en este ejemplo, ha estado funcionando durante dos horas y debería morir después de 60 minutos. la conexión con el host se rompe debido a un reinicio. Sería bueno que se agotara el tiempo de espera para manejar una conexión rota a menos que haya otra opción.

  - name: "Wait until Softnas Update completes. This can take 15-45 mins"
    wait_for:
      path: /tmp/softnas-update.status
      search_regex: "^OK. SoftNAS software update to version.*completed at.*$"
      timeout: 3600
    when: update_file.stat.exists and softnas_runupdate

Escribí un rol para lidiar con tareas de larga duración aquí: https://github.com/pillarsdotnet/ansible-watch.git

Gracias por compartir, ¡eso es genial!

@pillarsdotnet Parece que ansible no admite include_tasks con until (https://github.com/ansible/ansible/issues/17098). ¿Cómo lo hizo funcionar en el archivo /tasks/again.yml ? (Probé con ansible 2.7.8)

@lucasbasquerotto - Supongo que no funciona como esperaba. Debo repensar esto. Gracias.

Este comentario es esclarecedor:

Parece que en Ansible, si uno necesita hacer algo complejo, debe escribir un complemento de acción. Eso es lo que vamos a hacer.
Aquí uno tiene muchos ejemplos:
https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/action

Así que supongo que debería convertir loop.yml en un complemento de acción que llame a async_status y shell .

@pillarsdotnet Pude hacerlo funcionar haciendo un bucle en again.yml (usando el rango, entre 0 y el número de reintentos) y agregando un tiempo de espera en loop.yml (a _sleep_ en cada iteración ):

_ de nuevo.yml: _

- name: 'retries'
  set_fact:
    watch_retries: '{{ watch_timeout / watch_poll }}'

- name: 'checking {{ watch_job }} status until finished'
  include_tasks: 'loop.yml'
  loop: "{{ range(0, watch_retries | int, 1) | list }}"

_loop.yml: _

...

- wait_for:
    timeout: '{{ watch_poll | int }}'
  when: not watch_status.finished

...

Solo asegúrese de que el número de reintentos no sea demasiado grande, de lo contrario, podría devolver un error sobre la memoria o algo así (porque ansible hará cada inclusión antes de ejecutar el ciclo), por lo que si el tiempo de espera es 3600, haga una encuesta como 10 ( en lugar de 1) para que la inclusión se realice 360 ​​veces (en lugar de 3600).

Otra cosa es que si el trabajo de larga ejecución se ejecuta con algún usuario, la llamada async_status en loop.yml debe ser el mismo usuario (es importante tener esto en cuenta cuando se ejecuta con become: yes ).

Me encontré con este problema al intentar usar el módulo de script para uno de mis scripts de aprovisionamiento. No hay problema en los usos anteriores del módulo de secuencia de comandos (en el mismo libro de jugadas), pero por alguna razón en este se quedó colgado para siempre.

Luego intenté cambiar el módulo de script para copiar el script en mi /usr/bin/ y luego ejecutarlo con el módulo de shell, que funcionó.

pequeña mitigación, esto permite ver 'qué hosts se están ejecutando' # 53819

El mismo problema al usar ansible en la ventana acoplable.

ansible 2.7.8
  config file = None
  configured module search path = ['/home/jenkins/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.7/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.7.2 (default, Mar  5 2019, 06:22:51) [GCC 6.3.0 20170516]

Me enfrento a este problema al implementar exactamente las mismas máquinas virtuales (todas son clones de la misma máquina). Algunos de ellos obtienen el repositorio público clonado, mientras que otros simplemente cuelgan

Tengo el mismo problema con una sola tarea. Aquí está la salida con ANSIBLE_DEBUG=1 (poco redactado)

< TASK [myrole : Set Admnistrator SSH key] >
 ---------------------------------------------------- 
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

task path: /home/kvaps/git/myrepo/myproject/roles/myrole/tasks/myrole.yaml:54
 29952 1559645685.71733: sending task start callback
 29952 1559645685.71745: entering _queue_task() for stage/raw
 29952 1559645685.72714: worker is 1 (out of 1 available)
 29952 1559645685.72762: exiting _queue_task() for stage/raw
 29952 1559645685.72783: done queuing things up, now waiting for results queue to drain
 29952 1559645685.72794: waiting for pending results...
 30001 1559645685.73159: running TaskExecutor() for stage/TASK: myrole : Set Admnistrator SSH key
 30001 1559645685.73825: in run() - task 10e7c6f3-602f-cf0b-3453-000000000030
 30001 1559645685.74352: calling self._execute()
 30001 1559645685.75753: Loading TestModule 'core' from /usr/lib/python3.7/site-packages/ansible/plugins/test/core.py (found_in_cache=True, class_only=False)
 30001 1559645685.75836: Loading TestModule 'files' from /usr/lib/python3.7/site-packages/ansible/plugins/test/files.py (found_in_cache=True, class_only=False)
 30001 1559645685.75904: Loading TestModule 'mathstuff' from /usr/lib/python3.7/site-packages/ansible/plugins/test/mathstuff.py (found_in_cache=True, class_only=False)
 30001 1559645685.76498: Loading FilterModule 'core' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/core.py (found_in_cache=True, class_only=False)
 30001 1559645685.76653: Loading FilterModule 'ipaddr' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/ipaddr.py (found_in_cache=True, class_only=False)
 30001 1559645685.76768: Loading FilterModule 'json_query' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/json_query.py (found_in_cache=True, class_only=False)
 30001 1559645685.76894: Loading FilterModule 'k8s' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/k8s.py (found_in_cache=True, class_only=False)
 30001 1559645685.76996: Loading FilterModule 'mathstuff' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/mathstuff.py (found_in_cache=True, class_only=False)
 30001 1559645685.77076: Loading FilterModule 'network' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/network.py (found_in_cache=True, class_only=False)
 30001 1559645685.77162: Loading FilterModule 'urls' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/urls.py (found_in_cache=True, class_only=False)
 30001 1559645685.77279: Loading FilterModule 'urlsplit' from /usr/lib/python3.7/site-packages/ansible/plugins/filter/urlsplit.py (found_in_cache=True, class_only=False)
 30001 1559645685.83815: trying /usr/lib/python3.7/site-packages/ansible/plugins/lookup
 30001 1559645685.84568: Loaded config def from plugin (lookup/pipe)
 30001 1559645685.84578: Loading LookupModule 'pipe' from /usr/lib/python3.7/site-packages/ansible/plugins/lookup/pipe.py
 30001 1559645685.86089: Loaded config def from plugin (lookup/file)
 30001 1559645685.86108: Loading LookupModule 'file' from /usr/lib/python3.7/site-packages/ansible/plugins/lookup/file.py
 30001 1559645685.86125: File lookup term: /home/kvaps/git/myrepo/myproject/environments/stage/secrets/ssh_keys/administrator/id_rsa.pub
 30001 1559645685.86928: trying /usr/lib/python3.7/site-packages/ansible/plugins/connection
 30001 1559645685.87110: Loading Connection 'ssh' from /usr/lib/python3.7/site-packages/ansible/plugins/connection/ssh.py (found_in_cache=True, class_only=False)
 30001 1559645685.87329: trying /usr/lib/python3.7/site-packages/ansible/plugins/shell
 30001 1559645685.87513: Loading ShellModule 'sh' from /usr/lib/python3.7/site-packages/ansible/plugins/shell/sh.py (found_in_cache=True, class_only=False)
 30001 1559645685.87623: Loading ShellModule 'sh' from /usr/lib/python3.7/site-packages/ansible/plugins/shell/sh.py (found_in_cache=True, class_only=False)
 30001 1559645685.88879: Loading ActionModule 'raw' from /usr/lib/python3.7/site-packages/ansible/plugins/action/raw.py (searched paths: /usr/lib/python3.7/site-packages/ansible/plugins/action:/usr/lib/python3.7/site-packages/ansible/plugins/action/__pycache__) (found_in_cache=True, class_only=False)
 30001 1559645685.89061: starting attempt loop
 30001 1559645685.89151: running the handler
 30001 1559645685.89317: _low_level_execute_command(): starting
 30001 1559645685.89413: _low_level_execute_command(): executing: set user sshkey Administrator "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQChKqNqqtE+Va3WCSzf7QGRkackZ0dwX0RYF1r6QoVEqf2sXNa07GNjPyJ9lmUM3d6Az41pI5aJt6JVIxQfihaz4JNuoN5HqiZe/RCZ/ztBEY2UkVJfMH/PnFqNhBc1Y73DYkfA2N2BU3daju9Pah4sTwt4pDlAoZImyxw4gnJ0M7Z5hWtKIV/nK/5/FU5+CB9cMPQQB6BqmHRPk85SuyVOiCOYC1sseC6rafBSwM5/1IbHNVEDL/+scfJnmRnQSlAjytxz0jIXpkPCXC0AXDYpjElYsCPxyM/9JDqjiQ5HZ+WVl3Ou+oXZ67ag7eacIZGxTcAfb3dzw0+FDCZdOMhn root@admin"
<myhost.example.org> ESTABLISH SSH CONNECTION FOR USER: Administrator
<myhost.example.org> SSH: EXEC ssh -C -o ControlMaster=auto -o ControlPersist=60s -o StrictHostKeyChecking=no -o 'IdentityFile="/home/kvaps/git/myrepo/myproject/environments/stage/secrets/ssh_keys/administrator/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o 'User="Administrator"' -o ConnectTimeout=10 -o Ciphers=+aes128-cbc -o ControlPath=/home/kvaps/.ansible/cp/5dbae0ef82 -tt myhost.example.org 'set user sshkey Administrator "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQChKqNqqtE+Va3WCSzf7QGRkackZ0dwX0RYF1r6QoVEqf2sXNa07GNjPyJ9lmUM3d6Az41pI5aJt6JVIxQfihaz4JNuoN5HqiZe/RCZ/ztBEY2UkVJfMH/PnFqNhBc1Y73DYkfA2N2BU3daju9Pah4sTwt4pDlAoZImyxw4gnJ0M7Z5hWtKIV/nK/5/FU5+CB9cMPQQB6BqmHRPk85SuyVOiCOYC1sseC6rafBSwM5/1IbHNVEDL/+scfJnmRnQSlAjytxz0jIXpkPCXC0AXDYpjElYsCPxyM/9JDqjiQ5HZ+WVl3Ou+oXZ67ag7eacIZGxTcAfb3dzw0+FDCZdOMhn root@admin"'
 30001 1559645685.96164: stdout chunk (state=2):
>>>set user sshkey Administrator "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQChsiesjhJ9Vyo9WPxMvaytVkX3TAOCiAqMk1ay8D5UlbC6eKHU4fPbnLIt1dkU87+WMak4NAx8l/QurqrzimvUIVwtc6LLtvCj1ZY1GVDu9z3XFPno6xp63lQHMDGnf1jb0PalNWd86tlpR6uU/48BvzPutpZ86Hgp7cFBf7C94j33dO87/rnVdItUVgCIM+W4VtToEMZfMj8V9qKuOX9KW16z0MYBAqMKcY+jUVI6tpD1R+ltuuG+qG8omHG1RTAR5IpyrWYFDOfSk79N87gbZljaYAsdHfuc1f2mJLTZ5lmqT0ansOpqHwWXXxfieo8xKDplFyy6nb5HfJNE8qFDuuJkHwwnRqtjUTDomHYrS/+OKSXWcrOKYBzmgRZO0sRiZT+OJ6kL3nykzKPXOpzoJA09cUrmszaFSyixJZJlibXHjJ4b6dan0c0rIoBb7dQlzSiJw3G57lr8aj9LcjeqbYXrZDSPG7qy37azIyW65O514ZfosxQbjYaMZojfbAs= root@admin"

strace:

epoll_wait(10, [], 2, 7976)             = 0
wait4(31685, 0x7fff339a4c74, WNOHANG, NULL) = 0
epoll_wait(10, [], 2, 12000)            = 0
wait4(31685, 0x7fff339a4c74, WNOHANG, NULL) = 0
epoll_wait(10, [], 2, 12000)            = 0
wait4(31685, 0x7fff339a4c74, WNOHANG, NULL) = 0
epoll_wait(10, [], 2, 12000)            = 0
wait4(31685, 0x7fff339a4c74, WNOHANG, NULL) = 0

ansible:

ansible 2.8.0
  config file = /etc/ansible/ansible.cfg
  configured module search path = ['/home/kvaps/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.7/site-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.7.3 (default, Mar 26 2019, 21:43:19) [GCC 8.2.1 20181127]

Yo uso el módulo raw

Por cierto, arreglé esto agregando a ansible.cfg:

[ssh_connection]
control_path = none

+ etiqueta afecta_2.7

Lo mismo está sucediendo en # 57780 - ansible-playbook está esperando que el módulo shell termine en los hosts remotos y luego se cuelga para siempre cuando esta acción toma demasiado tiempo y numerosos "No se pueden asignar memoria "aparecen poco antes de eso. strace también muestra lo mismo que informaron otras personas aquí ( WNOHANG ).

Lo que no entiendo es por qué ciertos tiempos de espera no se activan. - p.ej:

connect_timeout
command_timeout
accelerate_timeout
accelerate_connect_timeout
accelerate_daemon_timeout

Este error se ha abierto durante más de 640 días y todavía está sucediendo.

Mis dos centavos:

Para mí, Ansible se bloquea porque configuro y habilito UFW en algún lugar de uno de mis libros de jugadas incluidos.

Cuando UFW está habilitado, los servidores de Ubuntu rompen los sockets abiertos después de una cierta cantidad de tiempo. Por lo tanto, Ansible podría continuar con la ejecución de otras tareas y, de repente, se cuelga más tarde, unos 15 segundos después de habilitar UFW.

La solución es configurar ubuntu para mantener activas las conexiones cuando se habilita el firewall.
Encontré la solución aquí: https://github.com/ansible/ansible/issues/45446

Me soluciona el problema:

- name: Configure the kernel to keep connections alive when enabling the firewall
  sysctl:
    name: net.netfilter.nf_conntrack_tcp_be_liberal
    value: 1
    state: present
    sysctl_set: yes
    reload: yes

- name: Enable ufw
  ufw: state=enabled

Lo arreglé configurando transport = paramiko en ansible.cfg

Todavía tengo el mismo problema con openstack-ansible
Probé todas las combinaciones anteriores de ansible.cfg pero no ayudé en nada :(

ansible --version configured module search path = [u'/etc/ansible/roles/config_template/library', u'/etc/ansible/roles/plugins/library', u'/etc/ansible/roles/ceph-ansible/library'] ansible python module location = /opt/ansible-runtime/lib/python2.7/site-packages/ansible executable location = /opt/ansible-runtime/bin/ansible python version = 2.7.5 (default, Jun 20 2019, 20:27:34) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)]
rastros:
# ansible -m setup 192.168.56.102 -vvv Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml " ansible 2.7.9 config file = None configured module search path = [u'/etc/ansible/roles/config_template/library', u'/etc/ansible/roles/plugins/library', u'/etc/ansible/roles/ceph-ansible/library'] ansible python module location = /opt/ansible-runtime/lib/python2.7/site-packages/ansible executable location = /opt/ansible-runtime/bin/ansible python version = 2.7.5 (default, Jun 20 2019, 20:27:34) [GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] No config file found; using defaults /opt/openstack-ansible/inventory/dynamic_inventory.py did not meet host_list requirements, check plugin documentation if this is unexpected Parsed /opt/openstack-ansible/inventory/dynamic_inventory.py inventory source with script plugin /opt/openstack-ansible/inventory/inventory.ini did not meet host_list requirements, check plugin documentation if this is unexpected /opt/openstack-ansible/inventory/inventory.ini did not meet script requirements, check plugin documentation if this is unexpected /opt/openstack-ansible/inventory/inventory.ini did not meet yaml requirements, check plugin documentation if this is unexpected Parsed /opt/openstack-ansible/inventory/inventory.ini inventory source with ini plugin /etc/openstack_deploy/inventory.ini did not meet host_list requirements, check plugin documentation if this is unexpected /etc/openstack_deploy/inventory.ini did not meet script requirements, check plugin documentation if this is unexpected /etc/openstack_deploy/inventory.ini did not meet yaml requirements, check plugin documentation if this is unexpected Parsed /etc/openstack_deploy/inventory.ini inventory source with ini plugin META: ran handlers Using module file /opt/ansible-runtime/lib/python2.7/site-packages/ansible/modules/system/setup.py <192.168.56.102> ESTABLISH SSH CONNECTION FOR USER: None <192.168.56.102> 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 ConnectTimeout=5 -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ServerAliveInterval=64 -o ServerAliveCountMax=1024 -o Compression=no -o TCPKeepAlive=yes -o VerifyHostKeyDNS=no -o ForwardX11=no -o ForwardAgent=yes -T -o ControlPath=none 192.168.56.102 '/bin/sh -c '"'"'/usr/bin/python && sleep 0'"'"''

apreciado cualquier ayuda
Gracias

@ rakeshz11

Viendo el mismo problema aquí a partir de esta mañana al ejecutar ansible a través del empaquetador. Literalmente no tengo idea de lo que cambió, pero esta mañana está roto 👍

Una cosa que noté con Ubuntu 18.04 (probada gota de $ 5 en Digital Ocean) es que si instalo ansible con pip3 (usando python3 , pero tal vez suceda con python2 y pip también) ansible se cuelga durante mucho tiempo en algunos casos (sucedió a veces, pero no siempre, pero si seguía ejecutando libros de jugadas, esto sucedía más de una vez de vez en cuando).

Lo extraño es que cuando ansible se colgó, incluso presionando Ctrl^C y tratando de ejecutar el libro de jugadas nuevamente, se colgó de inmediato, y ansible se colgó incluso cuando se ejecutaba ansible --version . Más extraño que eso es que incluso ejecutar python --version ahorcado (pero ejecutar echo "something" y ls funcionó bien). Incluso si me desconecté de SSH y me volví a conectar, continuó colgando durante algunos minutos (y luego funcionó nuevamente durante un tiempo).

Al final, desinstalé ansible (2.8) con pip3 y lo instalé con apt , y ya no ha sucedido.

Hola chicos.

En mi caso, Ansible estaba pendiente de "recopilar datos" debido a dos entradas en mis hosts_conocidos. Lo descubrí cuando intenté ssh manualmente:

Warning: the RSA host key for '****' differs from the key for the IP address '****'
Offending key for IP in /****/known_hosts:168
Matching host key in /****/known_hosts:368
Are you sure you want to continue connecting (yes/no)? ^C

Después de eliminar estas dos entradas y ejecutar ssh manualmente de nuevo (para poner la entrada correcta en known_hosts), Ansible ya no se bloqueó.

¡Espero eso ayude!

esto es un error vergonzoso pero a esta "empresa" no le importa una mierda de todos modos

Información realmente útil @gophobic ... gracias por tu aporte. 👍

Nuestra forma de solucionar este problema es ejecutar libros de jugadas usando -u (nombre de usuario) y tener un script bash ejecutándose que escanee y elimine las sesiones ssh abiertas que existen después de una cantidad de tiempo específica y elimine el PID cuando podemos asumir que el host es haciendo que el libro de jugadas se cuelgue. Por lo general, hago que esto suceda durante la etapa de recopilación de datos o alguna otra jugada ficticia que no tenga ningún impacto para verificar la conexión. Si todos los hosts problemáticos se eliminan con este método, simplemente fallan en el libro de jugadas y continuará durante el resto de las jugadas, ya que todos los hosts que provocarían el bloqueo ya han fallado.

Exploré la opción ANSIBLE_SHOW_PER_HOST_START = True que puede ayudar a identificar qué hosts están causando un problema, pero aún preferiría poder iniciar el libro de jugadas y saber que terminará y luego poder lidiar con cualquier falla que pueda haber sucedido después del hecho.

¿Sería posible implementar una verificación previa para asegurarse de que Ansible pueda conectarse a cada host y fallar de inmediato?

Nuestra forma de solucionar este problema es ejecutar libros de jugadas usando -u (nombre de usuario) y tener un script bash ejecutándose que escanee y elimine las sesiones ssh abiertas que existen después de una cantidad de tiempo específica y elimine el PID cuando podemos asumir que el host es haciendo que el libro de jugadas se cuelgue. Por lo general, hago que esto suceda durante la etapa de recopilación de datos o alguna otra jugada ficticia que no tenga ningún impacto para verificar la conexión. Si todos los hosts problemáticos se eliminan con este método, simplemente fallan en el libro de jugadas y continuará durante el resto de las jugadas, ya que todos los hosts que provocarían el bloqueo ya han fallado.

Haciendo lo mismo, pero raspando el sistema de archivos / proc para encontrar la hora de inicio del proceso ssh, luego matando después de n segundos. Desafortunadamente, eso activa SSH_RETRIES, por lo que el script de eliminación debe ejecutarse varias veces.

Ejecutamos un inventario de varios miles de hosts, por lo que no es práctico habilitar una mayor depuración para reducir el problema. Reducir el inventario a unos pocos cientos de hosts aún presenta el problema. Como han dicho otros, alternar mux, cambiar los parámetros de ControlMaster, canalizar, paramiko no ha ayudado.

En nuestro entorno, vemos que ha colgado los procesos ssh mux; strace muestra llamadas al sistema de sondeo, pero los procesos, si no se eliminan, permanecen activos durante horas / días. El proceso del supervisor ansible realmente necesita implementar una parada forzada o un tiempo de espera de cierre forzado.

Creo que esto también puede deberse a un descuido en la implementación de reintentos de conexión SSH (y falta / mala documentación por lo que pude ver).
Las conexiones SSH en ansible también están influenciadas por su .ssh / config local o el / etc / ssh / ssh_config de su host, además de los archivos ansible.cfg estándar.
Descubrí esto cuando intentaba diagnosticar bloqueos debido al módulo wait_for_connection.
Mientras se ejecute el comando SSH subyacente, no se imprime nada en los registros, incluso en los niveles de verbosidad que se muestran a continuación, porque ansible está realmente atascado esperando que SSH devuelva el control. Parece ser un exec () sincrónico.

Detalles de Ansible:

❯ ansible-playbook --version
ansible-playbook 2.9.0
  config file = None
  configured module search path = ['~/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/Cellar/ansible/2.9.0/libexec/lib/python3.7/site-packages/ansible
  executable location = /usr/local/bin/ansible-playbook
  python version = 3.7.5 (default, Nov  1 2019, 02:16:23) [Clang 11.0.0 (clang-1100.0.33.8)]

Lo siguiente se ejecutará durante 10 m , fuentes .ssh / config: ConnectionAttempts 10, no / default ansible.cfg:

❯ cat ans-test-conn.yml
- hosts: all
  gather_facts: false
  tasks:
      - name: Wait for 60s
        wait_for_connection:
            timeout: 60

❯ ansible-playbook -vvvvvvvv -i8.8.8.8, ans-test-conn.yml
[...]
<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s
  -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
  -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=~/.ansible/cp/28faeff4e9 8.8.8.8 '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
[...]
>>> elapsed time 11m12s

Lo siguiente se ejecutará durante 30 m , fuentes .ssh / config: ConnectionAttempts 10, SSH_ANSIBLE_RETRIES = 3:

❯ cat ans-test-conn.yml
- hosts: all
  gather_facts: false
  tasks:
      - name: Wait for 60s
        wait_for_connection:
            timeout: 60

❯ export SSH_ANSIBLE_RETRIES=3
❯ ansible-playbook -vvvvvvvv -i8.8.8.8, ans-test-conn.yml
[...]
<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s
  -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
  -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=~/.ansible/cp/28faeff4e9 8.8.8.8 '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
<8.8.8.8> (255, b'', b'OpenSSH_7.9p1, LibreSSL 2.7.3\r\ndebug1: Reading configuration data ~/.ssh/config\r\n
  [...]
  debug1: connect to address 8.8.8.8 port 22: Operation timed out\r\nssh: connect to host 8.8.8.8 port 22: Operation timed out\r\n')
<8.8.8.8> ssh_retry: attempt: 1, ssh return code is 255. cmd ([b'ssh', b'-vvv', b'-C', b'-o', b'ControlMaster=auto', b'-o', b'ControlPersist=60s',
  b'-o', b'KbdInteractiveAuthentication=no', b'-o', b'PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey',
  b'-o', b'PasswordAuthentication=no', b'-o', b'ConnectTimeout=10', b'-o', b'ControlPath=~/.ansible/cp/28faeff4e9',
  b'8.8.8.8', b"/bin/sh -c 'echo ~ && sleep 0'"]...), pausing for 0 seconds
<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster=auto -o ControlPersist=60s
  -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey
  -o PasswordAuthentication=no -o ConnectTimeout=10 -o ControlPath=~/.ansible/cp/28faeff4e9 8.8.8.8 '/bin/sh -c '"'"'echo ~ && sleep 0'"'"''
[...]
>>> elapsed time 30m43s

Lo siguiente en realidad volverá a intentar durante el tiempo que especificamos, 60s + 3 60s, porque estamos sobrescribiendo * tanto ConnectTimeout como ConnectionAttempts (no estoy seguro de si ControlMaster = no es realmente necesario, pero básicamente estaba reimplementando wait_for_connection y no quería chocar con el ControlMaster de host de salto persistente):

❯ cat ans-test-conn-2.yml
- hosts: all
  gather_facts: false
  tasks:
      - name: Wait for 60s
        connection: local
        shell: "ssh -oConnectTimeout=60s -oControlMaster=no -oConnectionAttempts=1 {{ inventory_hostname }} true"
        register: ssh_conn_result
        retries: 3
        delay: 1
        until: ssh_conn_result is not failed
[..]
<8.8.8.8> EXEC /bin/sh -c 'rm -f -r ~/.ansible/tmp/ansible-tmp-1573639556.634926-33012718610740/ > /dev/null 2>&1 && sleep 0'
FAILED - RETRYING: Wait for 60s (2 retries left).Result was: {
    "attempts": 2,
    "changed": true,
    "cmd": "ssh -oConnectTimeout=60s -oControlMaster=no -oConnectionAttempts=1 8.8.8.8 true",
    "delta": "0:01:00.052729",
    "end": "2019-11-13 11:06:56.841326",
    "invocation": {
        "module_args": {
            "_raw_params": "ssh -oConnectTimeout=60s -oControlMaster=no -oConnectionAttempts=1 8.8.8.8 true",
            "_uses_shell": true,
            "argv": null,
            "chdir": null,
            "creates": null,
            "executable": null,
            "removes": null,
            "stdin": null,
            "stdin_add_newline": true,
            "strip_empty_ends": true,
            "warn": true
        }
    },
    "msg": "non-zero return code",
    "rc": 255,
    "retries": 4,
    "start": "2019-11-13 11:05:56.788597",
    "stderr": "ssh: connect to host 8.8.8.8 port 22: Operation timed out",
    "stderr_lines": [
        "ssh: connect to host 8.8.8.8 port 22: Operation timed out"
    ],
    "stdout": "",
    "stdout_lines": []
}
[..]
>>> elapsed time 4m5s

1 intento inicial + 3 reintentos => 4 m.

La última secuencia de comandos sólo funcionará si usted no está detrás de un salto-host con comandos personalizada (siempre y cuando SSH gestiona la conexión en sí).
Si tiene un servidor de salto para conectarse al destino y tiene un comando de proxy personalizado, deberá aumentar la demora a 59-60 s para "reintentar cada minuto", de lo contrario, el comando proxy en el servidor de salto puede fallar inmediatamente. y delay: 1 haré que ansible ejecute todos los intentos lo más rápido posible.

Finalmente cambié al método de tracción ansible.

El miércoles 13 de noviembre de 2019 a las 3:04 a.m. Fabio Scaccabarozzi <
[email protected]> escribió:

Creo que esto también puede deberse a un descuido en la implementación de
Reintentos de conexión SSH (y falta / mala documentación en la medida de lo posible
ver).
Las conexiones SSH en ansible también están influenciadas por su .ssh / config local
o el / etc / ssh / ssh_config de su host además del estándar
archivos ansible.cfg.
Descubrí esto al intentar diagnosticar bloqueos debido a la
Wait_for_connection módulo.
Mientras se ejecute el comando SSH subyacente, no seimpreso en los registros, incluso en los niveles de verbosidad que se muestran a continuación, porque
ansible está realmente atascado esperando que SSH devuelva el control. Parece
ser un exec sincrónico ().

Detalles de Ansible:

❯ ansible-playbook --version

ansible-playbook 2.9.0

archivo de configuración = Ninguno

ruta de búsqueda de módulo configurado = ['~ / .ansible / plugins / modules', '/ usr / share / ansible / plugins / modules']

ansible python module location = /usr/local/Cellar/ansible/2.9.0/libexec/lib/python3.7/site-packages/ansible

ubicación ejecutable = / usr / local / bin / ansible-playbook

versión de python = 3.7.5 (predeterminado, 1 de noviembre de 2019, 02:16:23) [Clang 11.0.0 (clang-1100.0.33.8)]

Lo siguiente se ejecutará durante 10 m , fuentes .ssh / config: ConnectionAttempts
10, no / predeterminado ansible.cfg:

❯ cat ans-test-conn.yml

• hosts: todos

  reunir_factos: falso

  Tareas:

  • nombre: Espere 60

    espera_para_conexión:

    timeout: 60
    

❯ ansible-playbook -vvvvvvvv -i8.8.8.8, ans-test-conn.yml

[...]

<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster = auto -o ControlPersist = 60s

-o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey

-o PasswordAuthentication = no -o ConnectTimeout = 10 -o ControlPath = ~ / .ansible / cp / 28faeff4e9 8.8.8.8 '/ bin / sh -c' "'"' echo ~ && sleep 0 '"'" ''

[...]

tiempo transcurrido 11m12s

Lo siguiente se ejecutará durante 30 m , fuentes .ssh / config: ConnectionAttempts
10, SSH_ANSIBLE_RETRIES = 3:

❯ cat ans-test-conn.yml

• hosts: todos

  reunir_factos: falso

  Tareas:

  • nombre: Espere 60

    espera_para_conexión:

    timeout: 60
    

❯ exportar SSH_ANSIBLE_RETRIES = 3

❯ ansible-playbook -vvvvvvvv -i8.8.8.8, ans-test-conn.yml

[...]

<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster = auto -o ControlPersist = 60s

-o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey

-o PasswordAuthentication = no -o ConnectTimeout = 10 -o ControlPath = ~ / .ansible / cp / 28faeff4e9 8.8.8.8 '/ bin / sh -c' "'"' echo ~ && sleep 0 '"'" ''

<8.8.8.8> (255, b '', b'OpenSSH_7.9p1, LibreSSL 2.7.3 \ r \ ndebug1: Lectura de datos de configuración ~ / .ssh / config \ r \ n

[...]

debug1: conectarse a la dirección 8.8.8.8 puerto 22: operación agotada \ r \ nssh: conectarse al host 8.8.8.8 puerto 22: operación agotada \ r \ n ')

<8.8.8.8> ssh_retry: intento: 1, el código de retorno de ssh es 255. cmd ([b'ssh ', b'-vvv', b'-C ', b'-o', b'ControlMaster = auto ', b'-o ', b'ControlPersist = 60s',

b'-o ', b'KbdInteractiveAuthentication = no', b'-o ', b'PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey',

b'-o ', b'PasswordAuthentication = no', b'-o ', b'ConnectTimeout = 10', b'-o ', b'ControlPath = ~ / .ansible / cp / 28faeff4e9',

b'8.8.8.8 ', b "/ bin / sh -c' echo ~ && sleep 0 '"] ...), haciendo una pausa de 0 segundos

<8.8.8.8> SSH: EXEC ssh -vvv -C -o ControlMaster = auto -o ControlPersist = 60s

-o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey

-o PasswordAuthentication = no -o ConnectTimeout = 10 -o ControlPath = ~ / .ansible / cp / 28faeff4e9 8.8.8.8 '/ bin / sh -c' "'"' echo ~ && sleep 0 '"'" ''

[...]

tiempo transcurrido 30m43s

Lo siguiente realmente se ejecutará el tiempo que especifiquemos, 60s, porque estamos
sobrescribir tanto ConnectTimeout como ConnectionAttempts (no estoy seguro si
ControlMaster = no es realmente necesario, pero básicamente estaba reimplementando
wait_for_connection y no quería chocar con el host de salto persistente
ControlMaster):

❯ cat ans-test-conn-2.yml

• hosts: todos

  reunir_factos: falso

  Tareas:

  • nombre: Espere 60

    conexión: local

    shell: "ssh -oConnectTimeout = 60s -oControlMaster = no -oConnectionAttempts = 1 {{nombre_host_inventario}} verdadero"

    registro: ssh_conn_result

    reintentos: 3

    retraso: 1

    hasta que: ssh_conn_result no falle

[..]

<8.8.8.8> EXEC / bin / sh -c 'rm -f -r ~ / .ansible / tmp / ansible-tmp-1573639556.634926-33012718610740 /> / dev / null 2> & 1 && dormir 0'

ERROR - REINTENTANDO: Espere 60 segundos (quedan 2 reintentos). El resultado fue: {

"attempts": 2,

"changed": true,

"cmd": "ssh -oConnectTimeout=60s -oControlMaster=no -oConnectionAttempts=1 8.8.8.8 true",

"delta": "0:01:00.052729",

"end": "2019-11-13 11:06:56.841326",

"invocation": {

    "module_args": {

        "_raw_params": "ssh -oConnectTimeout=60s -oControlMaster=no -oConnectionAttempts=1 8.8.8.8 true",

        "_uses_shell": true,

        "argv": null,

        "chdir": null,

        "creates": null,

        "executable": null,

        "removes": null,

        "stdin": null,

        "stdin_add_newline": true,

        "strip_empty_ends": true,

        "warn": true

    }

},

"msg": "non-zero return code",

"rc": 255,

"retries": 4,

"start": "2019-11-13 11:05:56.788597",

"stderr": "ssh: connect to host 8.8.8.8 port 22: Operation timed out",

"stderr_lines": [

    "ssh: connect to host 8.8.8.8 port 22: Operation timed out"

],

"stdout": "",

"stdout_lines": []

}

[..]

tiempo transcurrido 4m5s

1 intento inicial + 3 reintentos => 4 m.

La última secuencia de comandos sólo funcionará si no está detrás de un salto-host con
comando personalizado (siempre que SSH maneje la conexión en sí).
Si tiene un host de salto para conectarse al destino y tiene un
proxy_command, deberá aumentar la demora a 59-60 s para "reintentar
cada minuto ", de lo contrario, el comando proxy en el host de salto puede fallar
inmediatamente, y demora: 1 hará que ansible ejecute todos los intentos tan rápido como
puede.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/30411?email_source=notifications&email_token=AFYYS45ZCK46WBT5ZXU32SDQTPNNVA5CNFSM4D3C4LI2YY3PNVWWK3TUL52HS4DFVREXG43VWWK3TUL52HS4DFVREXG43KSMVEDX5HFAment ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AFYYS43GNCJDVKSACEKRSWTQTPNNVANCNFSM4D3C4LIQ
.

-
Mira,
Imam Toufique
213-700-5485

ssh -o "ConnectTimeout 60" user@host
o
echo "ConnectTimeout 60" >> /etc/ssh/ssh_config

También enfrenté este problema. En mi caso, había ~/.ssh/config archivo

Host *.domain.tld
  ForwardAgent yes
  User user1
  IdentityFile /home/me/id_rsa

Después de eliminar el contenido del archivo, todo comenzó a funcionar.

En uno de nuestros proyectos usamos los comandos ad-hoc . Necesitábamos algo de tiempo para darnos cuenta de que era un error de Ansible. La razón principal es que el módulo setup funciona correctamente cuando ejecutamos:

ansible -m setup $IP

pero cuando lo ejecutamos programáticamente:

/bin/sh -c 'ansible -m setup $IP'

Cuelga para siempre en algunas máquinas.

Es muy importante para nosotros porque usamos el módulo setup para recuperar información sobre el sistema y luego los usamos para instalar los paquetes correctos y configurar la máquina.

Evitaríamos poner un tiempo de espera "difícil", pero intentaríamos resolver programáticamente algunos de los problemas más comunes que impiden que funcione setup

Dado que se trata de un problema muy conocido y "antiguo", creo que sería útil escribir un documento al respecto. ¿Existe tal documento? ¿Están los manteiners dispuestos a escribirlo? Si la respuesta es negativa, la escribiré yo mismo y les pediré contribuciones.

Estoy enfrentando un problema similar. Estoy ejecutando el comando RAW contra los routers Cisco y Juniper. Se cuelga solo para algunos de los dispositivos. Funciona el 90% de los dispositivos. Alguien puede ayudar. Adjuntar la salida de depuración después de ejecutar el comando
Así es como estoy ejecutando el comando
ansible all -i "$ DISPOSITIVOS," -m raw -a "$ COMMAND" -c paramiko --extra-vars "ansible_user = $ ans_user ansible_password = $ ans_password"

show_hang.txt

Estoy haciendo algo como esto:

- name: update system
  yum:
    name: '*'
    state: latest # noqa 403
  async: 600
  register: yum_sleeper

- name: 'YUM - check on async task'
  async_status:
    jid: "{{ yum_sleeper.ansible_job_id }}"
  register: job_result
  until: job_result.finished
  retries: 30

Gracias @tuxick. Parece que está haciendo reintentos.
Pero en mi caso simplemente cuelga. Puedo seguir intentándolo. El mismo problema.
Me las arreglé para agregar el tiempo de espera 45 frente al comando Ansible. Pero no resuelve mi problema.
timeout 45 ansible all -i "$ DISPOSITIVOS," -m raw -a "$ COMMAND" -c paramiko --extra-vars "ansible_user = $ ans_user ansible_password = $ ans_password"

¿Por qué está entregando? cuelga en
<10.121.0.3> SSH: EXEC sshpass -d8 ssh -vvv -C -o ControlPersist = 120s -o StrictHostKeyChecking = no -o 'Usuario = "usuario"' -o ConnectTimeout = 10 -o ControlPath = / root / .ansible / cp / 5992772463 -tt'mostrar descripciones de interfaces'

¿Alguien puede ayudar a mirar los registros o ha tenido una experiencia similar? Muchas gracias.

Tuve el mismo problema, sftp se estanca.
Probablemente, la mayoría de estos casos dependen de una configuración incorrecta de MTU.
No es raro que Ansible se esté ejecutando en algún tipo de red superpuesta, como VLAN o VxLAN. En este último caso, es necesario configurar correctamente el valor MTU de la función vtep para permitir la fragmentación de los frames.
Me enfrenté a este error en una VxLAN con valor MTU de la función VTEP de 1500 igual que el valor MTU de la red subyacente de 1500. Así que configuré un valor MTU de 1450 en VTEP (la encapsulación VxLAN necesita 50 bytes).

En mi configuración, la interfaz VTEP es eth100 @ eth100p, por lo que:

ip link set mtu 1450 eth100
ip link set mtu 1450 eth100p

Esto ha resuelto mi problema. Espero ayude.

Haciendo esto ahora con un inventario de ~ 200 hosts. Esta es la segunda vez que lo hago. Experiencia muy dolorosa. Detener todo el libro de jugadas debido a un host es bastante malo. Deberíamos poder declarar algo de max_time. Cada anfitrión en mi entorno necesita <1 s para recopilar datos. Un tiempo de espera de 30 segundos me solucionaría este problema.

En este caso, creo que un host está experimentando esto: SSH responde pero luego cuelga el inicio de sesión debido a que falta / home en ese host.

@halsafar : Sí, siempre pensé que ansible ejecuta el libro de jugadas para cada anfitrión de forma independiente y en paralelo. La aplicación del libro de jugadas en un host no debería perturbar la de otro.

Cuando no sea necesario, NO recopile datos; de lo contrario, obtenga lo que necesita.

Entonces, en los libros de

- hosts: hostgroup
  gather_facts: no
  tasks:
  - name: Collect only network facts 
    setup:
      gather_subset:
        - '!all'
        - network

y reúne justo lo que _realmente_ necesita, con el beneficio adicional de acelerar todo el proceso.

En el comando ad-hoc tienes algo como:

ansible -m <MODULE> -a "gather_subset=!all,network"

También puede configurar este archivo de configuración.

Referencias

• Documento del módulo de configuración
• Vea este hilo de stackoverflow para diferentes ejemplos de contexto

Nota

Verifique la sintaxis de yml.

Cuando no sea necesario, NO recopile datos; de lo contrario, obtenga lo que necesita.

Entonces, en los libros de

- hosts: hostgroup
  gather_facts: no
  tasks:
  - name: Collect only network facts 
    setup:
      gather_subset:
        - '!all'
        - network

y reúne justo lo que _realmente_ necesita, con el beneficio adicional de acelerar todo el proceso.

En el comando ad-hoc tienes algo como:

ansible -m <MODULE> -a "gather_subset=!all,network"

También puede configurar este archivo de configuración.

Referencias

• Documento del módulo de configuración
• Vea este hilo de stackoverflow para diferentes ejemplos de contexto

Nota

Verifique la sintaxis de yml.

Ayuda, pero algunos módulos se basan en la capa FS del sistema, y ​​si tiene algún NFS colgando, se bloqueará

Experimentamos este error a diario en un grupo de aproximadamente 40K hosts. Viene y desaparece según el estado de los hosts. Hasta ahora, la única solución real es dividir los trabajos ansible en lotes más pequeños en nuestra orquestación (estamos usando http://screwdriver.cd). Esto minimiza el dolor, pero lo es.

Nuestro libro de jugadas es para auditoría, es mínimo y está optimizado para la velocidad sin recopilar datos, etc.

• copiar un archivo a hosts
• ejecutar ese archivo
• copiar los resultados del host

Existe un problema fundamental por el que no se respetan los valores de tiempo de espera especificados. Si se inicia un programa en el cliente, pero se encuentra en un estado de suspensión en ejecución, porque, por ejemplo, queda bloqueado. O tal vez ssh no funciona como se esperaba: la conexión ssh (sospechada) se realiza correctamente, pero el shell remoto no termina de abrirse debido a un problema en el nivel del host. Esta última condición se puede observar incluso a mano cuando el cliente ssh no respeta su propio tiempo de espera, tampoco, cuando se intenta ssh al cliente malo.

Esto se convierte en un gran bloqueador a medida que aumenta la escala de lo que está trabajando. Mi equipo tiene presión para que esto funcione. Esto significa que necesito hacer funcionar algún truco o cambiar a otro software de control de trabajos. Es lamentable que este error haya estado abierto tanto tiempo

@jgurtz
a esa escala, ya te has respondido cuál será la solución.
pero, también, repase el último año de los comentarios de este boleto. HABÍA 1-2 personas en los últimos 2 años con información muy útil. Si estuviera en su lugar, los buscaría como una solución provisional. Pero el problema de raíz probablemente no desaparecerá.

Gracias por la respuesta. He hecho referencia a este hilo varias veces durante el último año y AFAIKT, hay mitigaciones pero no soluciones para este problema. Si me he perdido algo innovador, por favor, menciónelo.

Veo a algunas personas en este hilo que experimentan este problema con una cantidad menor de hosts y aparentemente también conmutadores / enrutadores empresariales. Seguro que desearía haber sabido de este error antes de comenzar.

En casi todos mis casos, -vvvv mostró lo suficiente para determinar los problemas de ssh relacionados con la autenticación, contraseñas, claves, etc. No diría que esto se ajusta a otros, pero para mí es cierto. Sería bueno si ansible proporcionara más detalles sobre los problemas de autenticación sin tener que volver a ejecutar con -vvvv aunque ...

Solucionar problemas de conexión individuales no es el camino a seguir. Una vez que tienes un
obtener miles de sistemas, siempre habrá algunos problemáticos. De nuevo en
'14 Simplemente tenía 2 libros de jugadas de preacondicionamiento que tenían conectividad y
pruebas y solo los supervivientes se utilizaron para el inventario real. Pero
eso también significa que mi inventario no era dinámico. No tiene mucho sentido :-)

Pero, lo que quería señalar es ...:

Para mí, el post más interesante del hilo fue el de Fabio. Esta
da un comportamiento de tiempo de espera determinista si entiendo bien:

Lo siguiente realmente se ejecutará el tiempo que especifiquemos, 60s, porque estamos
sobrescribir tanto ConnectTimeout como ConnectionAttempts (no estoy seguro si
ControlMaster = no es realmente necesario, pero básicamente estaba reimplementando
wait_for_connection y no quería chocar con el host de salto persistente
ControlMaster):

Jason Gurtz [email protected] schrieb am Do., 30 de abril de 2020, 22:26:

Gracias por la respuesta. He hecho referencia a este hilo varias veces.
el último año y AFAIKT, hay mitigaciones pero no hay soluciones para esto
problema. Si me he perdido algo innovador, por favor, menciónelo.

Veo que algunas personas en este hilo experimentan este problema con órdenes de
magnitud menor cantidad de hosts y aparentemente conmutadores / enrutadores empresariales
también. Seguro que desearía haber sabido de este error antes de comenzar.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/30411#issuecomment-622091204 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAVSVG74SBNZY624W3MYL2DRPHNINANCNFSM4D3C4LIQ
.

no soluciona 'por qué las cosas se cuelgan', pero puede crear una forma de evitar que detengan una ejecución de juego # 69284

Si se cuelga de sshpass (y se utiliza el parámetro ControlPersist), consulte https://sourceforge.net/p/sshpass/patches/11/

+1, nos enfrentamos exactamente al mismo problema cuando se trata de inventarios más grandes, no tengo ni idea de por qué anisble está bloqueado y bloqueado con qué host ... ¿podemos tener una opción que muestre algunos detalles del host problemático cuando se cuelgue al menos? ...

@ Sreenadh8 ejecutándose con -vvv le mostrará los hosts a los que intenta conectarse, no es genial, pero puede contrastar eso con la salida de 'resultados' para averiguar en qué hosts está atascado.

Estaba encontrando problemas en este sentido con solo un puñado de hosts de destino y logré identificar dos causas raíz plausibles:

• invocaciones concurrentes de Ansible peleando por los archivos ControlPersist
• Ansible intenta reutilizar la conexión SSH existente después de que se reinicia el host remoto y luego no se agota el tiempo de espera

La solución principal parecía ser que las invocaciones potencialmente concurrentes definieran ubicaciones distintas para ControlPath, pero también comenzamos a eliminar explícitamente los archivos de persistencia cuando teníamos buenas razones para creer que ya no serían válidos.

Desafortunadamente, depurar este tipo de problema es muy doloroso, ya que hay muchos problemas potenciales subyacentes de SSH que se manifiestan como "Ansible cuelga una llamada SSH sin tiempo de espera" :(

@ncoghlan meta: reset_connection debería manejar la eliminación del archivo de persistencia de control obsoleto, le recomiendo que lo use después de la acción reboot .

No son solo problemas de ssh, muchas veces ssh está bien, pero sshpass o el proceso en el otro extremo se cuelga / tarda mucho / bloquear. Intentamos continuamente eliminar las posibles formas en que se colgará, pero esto probablemente nunca se resolverá al 100% ... solo intentamos acercarnos lo más posible a él.

¿Ha revisado el parche que mencioné hace algunas publicaciones? Encontramos el mismo problema (o similar) en nuestro producto y resultó ser un error de sshpass. Una especie de condición de carrera. Y la probabilidad de golpearlo parecía estar correlacionada con la carga del host donde se estaba ejecutando ansible. En nuestro caso, teníamos muchos hosts que estábamos implementando con ansible y esto causó una mayor carga y una mayor probabilidad de encontrar el problema. Pero me imagino que podríamos lograrlo con una menor cantidad de hosts si nuestro host ansible tuviera una carga de CPU más alta por alguna otra razón.
Por favor, consulte https://sourceforge.net/p/sshpass/patches/11/ ponemos una explicación más detallada del problema. Y compile y pruebe la versión fija de sshpass.

La causa del problema puede estar relacionada con problemas de apt con la red ipv6, deshabilitar ipv6 o preferir que ipv4 funcionó para mí, vea un foro sobre eso

Hola,

Soy Reshma.Tengo un problema similar al de mi módulo ansible que se ejecuta simplemente atascado y no me da fallas / omitido / estado y no hace nada en el host de destino. si alguien pudiera ayudar con esto, sería genial. Si este no es el foro correcto, por favor ayude a fijar el foro en el que pueda buscar ayuda.

Detalles del sistema:
Anfitrión de destino: SUSE 12 SP5
python-xml-2.7.17-28.51.1.x86_64
rpm-4.11.2-16.21.1.x86_64
zypper 1.13.51

Comando Ansible:
ANSIBLE_DEBUG = 1 ansible -i / etc / ansible / hosts webservers -k -m zypper -a 'nombre = git-core estado = presente' -v

Salida de depuración:
3676 1600772716.28160: _low_level_execute_command (): ejecutando: / bin / sh -c 'echo PLATFORM; tu nombre; echo ENCONTRADO; comando -v '"'" '/ usr / bin / python' "'"'; comando -v '"'" 'python3.7' "'"'; comando -v '"'" 'python3.6' "'"'; comando -v '"'" 'python3.5' "'"'; comando -v '"'" 'python2.7' "'"'; comando -v '"'" 'python2.6' "'"'; comando -v '"'" '/ usr / libexec / platform-python' "'"'; comando -v '"'" '/ usr / bin / python3' "'"'; comando -v '"'" 'python' "'"'; echo ENDFOUND && dormir 0 '
3676 1600772716.37768: fragmento de salida estándar (estado = 2):

PLATAFORMA
<<<

3676 1600772716.37947: fragmento de salida estándar (estado = 3):

Linux
ENCONTRÓ
/ usr / bin / python
<<<

3676 1600772716.37989: fragmento de salida estándar (estado = 3):

/usr/bin/python3.6
/usr/bin/python2.7
/ usr / bin / python3
/ usr / bin / python
FINALIZADO
<<<

3676 1600772716.38378: fragmento stderr (estado = 3):

<<<

3676 1600772716.38424: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.38484: _low_level_execute_command () hecho: rc = 0, stdout = PLATAFORMA
Linux
ENCONTRÓ
/ usr / bin / python
/usr/bin/python3.6
/usr/bin/python2.7
/ usr / bin / python3
/ usr / bin / python
FINALIZADO
, stderr =
3676 1600772716.38530 [10.237.222.108]: intérpretes encontrados: [u '/ usr / bin / python', u '/ usr / bin / python3.6', u '/ usr / bin / python2.7', u '/ usr / bin / python3 ', u' / usr / bin / python ']
3676 1600772716.38609: _low_level_execute_command (): iniciando
3676 1600772716.38650: _low_level_execute_command (): ejecutando: / bin / sh -c '/ usr / bin / python && sleep 0'
3676 1600772716.39569: Envío de datos iniciales
3676 1600772716.39658: Datos iniciales enviados (1234 bytes)
3676 1600772716.51494: fragmento de salida estándar (estado = 3):

{"osrelease_content": "NAME = \" SLES \ "\ nVERSION = \" 12-SP5 \ "\ nVERSION_ID = \" 12.5 \ "\ nPRETTY_NAME = \" SUSE Linux Enterprise Server 12 SP5 \ "\ nID = \" sles \ "\ nANSI_COLOR = \" 0; 32 \ "\ nCPE_NAME = \" cpe: / o: suse :
<<<

3676 1600772716.51914: fragmento stderr (estado = 3):

<<<

3676 1600772716.51960: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.52014: _low_level_execute_command () done: rc = 0, stdout = {"osrelease_content": "NAME = \" SLES \ "\ nVERSION = \" 12-SP5 \ "\ nVERSION_ID = \" 12.5 \ "\ nPRETTY_NAME = \" SUSE Linux Enterprise Server 12 SP5 \ "\ nID = \" sles \ "\ nANSI_COLOR = \" 0; 32 \ "\ nCPE_NAME = \" cpe: / o : suse :
, stderr =
3676 1600772716.52196: ANSIBALLZ: usando el módulo en caché: /root/.ansible/tmp/ansible-local-3668A5bmKd/ansiballz_cache/zypper-ZIP_DEFLATED
3676 1600772716.52622: módulo de transferencia a /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py remoto
3676 1600772716.53785: Envío de datos iniciales
3676 1600772716.53856: Datos iniciales enviados (138 bytes)
3676 1600772716.63011: fragmento de salida estándar (estado = 3):

sftp> put /root/.ansible/tmp/ansible-local-3668A5bmKd/tmpduCRmY /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py
<<<

3676 1600772716.65358: fragmento stderr (estado = 3):

<<<

3676 1600772716.65404: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.65466: terminado de transferir el módulo al control remoto
3676 1600772716.65532: _low_level_execute_command (): iniciando
3676 1600772716.65568: _low_level_execute_command (): ejecutando: / bin / sh -c 'chmod u + x /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/ /root/.ansible/tmp/ansible-tmp-1600772715.9- 203940692219450 / AnsiballZ_zypper.py && dormir 0 '
3676 1600772716.75915: fragmento stderr (estado = 2):

<<<

3676 1600772716.76007: fragmento de salida estándar (estado = 2):

<<<

3676 1600772716.76066: _low_level_execute_command () hecho: rc = 0, stdout =, stderr =
3676 1600772716.76099: _low_level_execute_command (): iniciando
3676 1600772716.76141: _low_level_execute_command (): ejecutando: / bin / sh -c '/ usr / bin / python /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py && dormir 0'

Descubrí que simplemente matar un proceso atascado en el control remoto a través de ssh devuelve el stdout. Encuentro que eso es más corto que escribir soluciones que no se usarán en el libro de jugadas final de todos modos:

kill -9 PID

intentalo

Este es un problema con la configuración del proxy en la máquina de destino de SUSE, por lo tanto, en la máquina de destino, agregue el proxy como se menciona en el siguiente enlace https://www.suse.com/support/kb/doc/?id=000017441

Debido a que el módulo zypper no se puede instalar.

Hola,

Soy Reshma.Tengo un problema similar al de mi módulo ansible que se ejecuta simplemente atascado y no me da fallas / omitido / estado y no hace nada en el host de destino. si alguien pudiera ayudar con esto, sería genial. Si este no es el foro correcto, por favor ayude a fijar el foro en el que pueda buscar ayuda.

Detalles del sistema:
Anfitrión de destino: SUSE 12 SP5
python-xml-2.7.17-28.51.1.x86_64
rpm-4.11.2-16.21.1.x86_64
zypper 1.13.51

Comando Ansible:
ANSIBLE_DEBUG = 1 ansible -i / etc / ansible / hosts webservers -k -m zypper -a 'nombre = git-core estado = presente' -v

Salida de depuración:
3676 1600772716.28160: _low_level_execute_command (): ejecutando: / bin / sh -c 'echo PLATFORM; tu nombre; echo ENCONTRADO; comando -v '"'" '/ usr / bin / python' "'"'; comando -v '"'" 'python3.7' "'"'; comando -v '"'" 'python3.6' "'"'; comando -v '"'" 'python3.5' "'"'; comando -v '"'" 'python2.7' "'"'; comando -v '"'" 'python2.6' "'"'; comando -v '"'" '/ usr / libexec / platform-python' "'"'; comando -v '"'" '/ usr / bin / python3' "'"'; comando -v '"'" 'python' "'"'; echo ENDFOUND && dormir 0 '
3676 1600772716.37768: fragmento de salida estándar (estado = 2):

PLATAFORMA
<<<

3676 1600772716.37947: fragmento de salida estándar (estado = 3):

Linux
ENCONTRÓ
/ usr / bin / python
<<<

3676 1600772716.37989: fragmento de salida estándar (estado = 3):

/usr/bin/python3.6
/usr/bin/python2.7
/ usr / bin / python3
/ usr / bin / python
FINALIZADO
<<<

3676 1600772716.38378: fragmento stderr (estado = 3):

<<<

3676 1600772716.38424: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.38484: _low_level_execute_command () hecho: rc = 0, stdout = PLATAFORMA
Linux
ENCONTRÓ
/ usr / bin / python
/usr/bin/python3.6
/usr/bin/python2.7
/ usr / bin / python3
/ usr / bin / python
FINALIZADO
, stderr =
3676 1600772716.38530 [10.237.222.108]: intérpretes encontrados: [u '/ usr / bin / python', u '/ usr / bin / python3.6', u '/ usr / bin / python2.7', u '/ usr / bin / python3 ', u' / usr / bin / python ']
3676 1600772716.38609: _low_level_execute_command (): iniciando
3676 1600772716.38650: _low_level_execute_command (): ejecutando: / bin / sh -c '/ usr / bin / python && sleep 0'
3676 1600772716.39569: Envío de datos iniciales
3676 1600772716.39658: Datos iniciales enviados (1234 bytes)
3676 1600772716.51494: fragmento de salida estándar (estado = 3):

{"osrelease_content": "NAME =" SLES "\ nVERSION =" 12-SP5 "\ nVERSION_ID =" 12.5 "\ nPRETTY_NAME =" SUSE Linux Enterprise Server 12 SP5 "\ nID =" sles "\ nANSI_COLOR =" 0; 32 " \ nCPE_NAME = "cpe: / o: suse: sles : 12: sp5" \ n "," platform_dist_result ": [" SuSE "," 12 "," x86_64 "]}
<<<

3676 1600772716.51914: fragmento stderr (estado = 3):

<<<

3676 1600772716.51960: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.52014: _low_level_execute_command () done: rc = 0, stdout = {"osrelease_content": "NAME =" SLES "\ nVERSION =" 12-SP5 "\ nVERSION_ID =" 12.5 "\ nPRETTY_NAME =" SUSE Linux Enterprise Server 12 SP5 " \ nID = "sles" \ nANSI_COLOR = "0; 32" \ nCPE_NAME = "cpe: / o: suse :
, stderr =
3676 1600772716.52196: ANSIBALLZ: usando el módulo en caché: /root/.ansible/tmp/ansible-local-3668A5bmKd/ansiballz_cache/zypper-ZIP_DEFLATED
3676 1600772716.52622: módulo de transferencia a /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py remoto
3676 1600772716.53785: Envío de datos iniciales
3676 1600772716.53856: Datos iniciales enviados (138 bytes)
3676 1600772716.63011: fragmento de salida estándar (estado = 3):

sftp> put /root/.ansible/tmp/ansible-local-3668A5bmKd/tmpduCRmY /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py
<<<

3676 1600772716.65358: fragmento stderr (estado = 3):

<<<

3676 1600772716.65404: fragmento de salida estándar (estado = 3):

<<<

3676 1600772716.65466: terminado de transferir el módulo al control remoto
3676 1600772716.65532: _low_level_execute_command (): iniciando
3676 1600772716.65568: _low_level_execute_command (): ejecutando: / bin / sh -c 'chmod u + x /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/ /root/.ansible/tmp/ansible-tmp-1600772715.9- 203940692219450 / AnsiballZ_zypper.py && dormir 0 '
3676 1600772716.75915: fragmento stderr (estado = 2):

<<<

3676 1600772716.76007: fragmento de salida estándar (estado = 2):

<<<

3676 1600772716.76066: _low_level_execute_command () hecho: rc = 0, stdout =, stderr =
3676 1600772716.76099: _low_level_execute_command (): iniciando
3676 1600772716.76141: _low_level_execute_command (): ejecutando: / bin / sh -c '/ usr / bin / python /root/.ansible/tmp/ansible-tmp-1600772715.9-203940692219450/AnsiballZ_zypper.py && dormir 0'

Este es un problema con la configuración del proxy en la máquina de destino de SUSE, por lo tanto, en la máquina de destino, agregue el proxy como se menciona en el siguiente enlace https://www.suse.com/support/kb/doc/?id=000017441

Debido a que el módulo zypper no se puede instalar.