Ansible: [openssh / linux kernel> 3.12] Error intermitente "no se pudo resolver el directorio temporal remoto desde" [dormir 0]

Hola,
También toso eso con la bandera -vvvv .

<45.56.96.138> ESTABLISH SSH CONNECTION FOR USER: root
<45.56.96.138> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o 'IdentityFile="/home/riversy/.ssh/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/home/riversy/.ansible/cp/ansible-ssh-%h-%p-%r -tt 45.56.96.138 'mkdir -p "$( echo $HOME/.ansible/tmp/ansible-tmp-1453707878.36-19081627291623 )" && echo "$( echo $HOME/.ansible/tmp/ansible-tmp-1453707878.36-19081627291623 )"'
fatal: [45.56.96.138]: FAILED! => {"failed": true, "msg": "ERROR! failed to resolve remote temporary directory from ansible-tmp-1453707878.36-19081627291623: `mkdir -p \"$( echo $HOME/.ansible/tmp/ansible-tmp-1453707878.36-19081627291623 )\" && echo \"$( echo $HOME/.ansible/tmp/ansible-tmp-1453707878.36-19081627291623 )\"` returned empty string"}

Mi versión de ansible es:

ansible 2.0.0.2
  config file = /etc/ansible/ansible.cfg
  configured module search path = Default w/o overrides

Agradeceré cualquier consejo.

Actualización: A veces también sucede incluso en: ansible all -i inventory/test -m ping comando.

Me he dado cuenta de que si ejecuto un libro de jugadas de forma consecutiva, generalmente obtengo éxito.

ES DECIR

Ejecutar # 1:
fatal: [1.2.3.4]: ¡FALLIDO! => {"failed": true, "msg": "no se pudo resolver el directorio temporal remoto de ansible-tmp-1453754269.23-53039386122234: ( umask 22 && mkdir -p \"$( echo $HOME/.ansible/tmp/ansible-tmp-1453754269.23-53039386122234 )\" && echo \"$( echo $HOME/.ansible/tmp/ansible-tmp-1453754269.23-53039386122234 )\" ) devolvió una cadena vacía"}

Ejecutar # 2: Éxito

Sin embargo, esperando ~ un minuto, la falla volverá a ocurrir. Monitoreando la máquina remota no veo el ~ / .ansible / tmp /

También comenzó a experimentar el error después de actualizar de Ansible 1.9.4 a 2.0.0.2.

Dudo que importe, pero por si acaso es un VPS CentOS 7.1 alojado en Linode.

Encontré esto en tareas de shell / comando aleatorias en un libro de jugadas contra un vps de CentOS en Amazon. Esa es nuestra única máquina CentOS 7.2 con más de 20 servidores ami de Amazon que no han mostrado el problema hasta ahora.

Intenté 2.0.0, 2.0.0.2, 2.1, activación / desactivación de canalización, activación / desactivación de controlpersist y ejecutándome desde OS X / amazon ami. También intenté eliminar los archivos .ansible del nodo de destino sin ningún efecto

Es posible que esto no esté relacionado, pero terminé resolviendo este problema por ahora reiniciando la máquina. Había notado que registros como este mencionaban un registro btmp dañado y ejecuté 'cat / dev / null> / var / log / btmp', seguido de un reinicio. Es posible que lo btmp no esté relacionado, pero estaba iniciando sesión en cada comando / conexión ansible. Había movido mi partición / var a un disco diferente el día anterior, es posible que se haya corrompido por eso.

sshd [24031]: pam_unix (sshd: sesión): sesión cerrada para el usuario centos
sshd [24248]: clave pública aceptada para centos desde el puerto 45694 ssh2:
sshd [24248]: pam_unix (sshd: sesión): sesión abierta para el usuario centos por (uid = 0)
sshd [24248]: pam_lastlog (sshd: sesión): corrupción detectada en / var / log / btmp
sshd [24251]: desconexión recibida de: 11: desconectado por el usuario

@mgaley basándome en sus comentarios, miré la conexión ssh con mi cliente y encontré algo interesante.

Estoy usando RHEL 6.6 para máquinas de origen y destino y Ansible 2.0.0.2

Remoteserver #> tail -f / var / log / secure

27 de enero 07:47:48 Remoteserver sshd [19329]: clave pública aceptada para jenkins desde el puerto de Ansiblehost 41384 ssh2
27 de enero 07:47:48 Remoteserver sshd [19329]: pam_unix (sshd: sesión): sesión abierta para el usuario jenkins por (uid = 0)

<< --- >>
Ansibleserver: ¡ERROR! no pudo resolver el directorio temporal remoto

La conexión SSH permanece establecida por el PID de Ansible (pero no el pid original que lo abre, supongo que se espera)

Ejecutar nuevamente dentro de la ventana de los 60 donde la conexión permanece establecida produjo mi resultado de éxito anterior

"ControlPersist = 60s"
<<-->>
Reintentar el libro de jugadas (se utiliza la sesión SSH establecida anterior)

27 de enero 07:48:11 Remoteserver sshd [19333]: solicitud de subsistema para sftp
27 de enero 07:48:12 Remoteserver sshd [19333]: solicitud de subsistema para sftp
27 de enero 07:49:13 Remoteserver sshd [19333]: desconexión recibida de Ansiblehost: 11: desconectado por el usuario
27 de enero 07:49:13 Remoteserver sshd [19329]: pam_unix (sshd: sesión): sesión cerrada para el usuario jenkins

El libro de jugadas se completa con éxito.

Veo el mismo problema también corriendo
ansible 2.1.0 (devel 4b1d621442) última actualización 2016/01/28 19:20:32 (GMT -400)

También tuve el mismo problema al usar el mismo libro de jugadas contra 5 servidores ami de amazon en 5 bloques separados de una jugada, solo contra el primer nodo. No vi nada relacionado en el registro seguro esta vez.

Solo en lo relacionado con los módulos de shell / comando, ejecutar varios libros de jugadas al mismo tiempo localmente, incluso en los mismos hosts remotos, no provocó que el error ocurriera con más frecuencia.

También obtenemos esto. ¿Es interesante observar https://groups.google.com/forum/#!msg/ansible -devel / 5i6VDHKZ30I / 0ksVpEEICwAJ la posibilidad de una condición de carrera en la creación de directorios?

Yo también estoy viendo esto. Parece suceder aleatoriamente en tareas arbitrarias en un libro de jugadas, siempre con respecto a este archivo tmp. Solo vuelvo a ejecutar el libro de jugadas hasta que funcione. Estoy usando un sistema de archivos de red (almacenamiento en bloque de espacio en rack).

A mí también me pasa. Verdaderamente al azar parece.

https://github.com/ansible/ansible/blob/200f95887373e215eb41adb3dcc4128a0a0e0f88/lib/ansible/plugins/action/__init__.py

Hay dos problemas aquí.

1. No use la caída como establecer rc en / para marcar que algo salió mal. El enfoque de manejo de errores en este archivo es defectuoso. Mi opinión - ¡discuta!
2. En la función _make_tmp_path encontramos lo que creo que es la causa raíz y por qué ejecutar el libro de jugadas dos veces soluciona el problema. Sospecho, aunque no lo he confirmado, que esto nunca ocurre más de una vez en un servidor determinado.

Sospecho que hay algo que ver con cómo funciona la función mkdtemp en el archivo https://github.com/ansible/ansible/blob/42e312d3bd0516ceaf2b4533ac643bd9e05163cd/lib/ansible/plugins/shell/sh.py .

¿Alguien siente que estoy completamente equivocado?

+1 obteniendo el mismo problema. Realmente aleatorio

Estoy obteniendo lo mismo, usando archlinux vagrant controller y archlinux vagrant targets.
Todas las cajas están en ansible v 2.0.0.2

Esto es causado por un error en el kernel de Linux o en openssh, no estoy seguro de cuál es el culpable.
https://bugzilla.mindrot.org/show_bug.cgi?id=2492
https://lkml.org/lkml/2015/12/9/775

Una solución es degradar el kernel de Linux en el servidor a una versión que no incluya la confirmación 1a48632ffed61352a7810ce089dc5a8bcd505a60. Para Ubuntu 14.04, esto es, por ejemplo, 3.16.0-60, 3.19.0-22 o anterior.

Estoy ejecutando el kernel 2.6.32-504 (rhel 6.6). Y este error solo ocurre en Ansible 2.x, no en versiones anteriores.

Estoy usando el kernel 4.3.3-3-ARCH y no estoy interesado en volver a los kernels 3.x en estas máquinas.

Otra solución alternativa sería utilizar un transporte diferente a Openssh (¿paramiko?).

Voy a cerrar este boleto ya que Ansible en sí no está haciendo nada malo aquí, esta es solo una mala interacción entre las herramientas de las que dependemos.

¿Por qué solo comenzó a aparecer después de que la gente cambiara de Ansible 1.9.xa Ansible 2.0.x?

Sin discutir que no es un problema con las herramientas subyacentes, solo tengo curiosidad genuina de por qué no era un problema antes.

No estoy seguro de cómo se considera resuelto esto ... @rpsiv confirmó que también sucede con kernels más antiguos, por lo que no es un error del kernel. No le sucedió a nadie antes de Ansible 2.0.xy ahora está muy extendido.

entre herramientas de las que dependemos

¿Cuáles son estas herramientas a las que te refieres @bcoca ? Estaría feliz de encontrar la causa raíz y ayudar a solucionarlo trabajando con otros equipos de código abierto, sin embargo, en este punto no tengo claro por dónde debería (nosotros) comenzar. Gracias.

@bcoca : ping?
La cosa funciona perfectamente en 1.9.4.
Después de todo, si ve la fuente del problema, considere agregar una solución en ansible v2.x

El hecho de que esto suceda solo una vez en cada servidor es una pista, creo.

@khushil , ha sucedido varias veces en algunos de nuestros servidores, incluso reiniciarlos, etc.no ayudó. A veces, el problema desaparece de repente, pero a veces, no importa lo que hagamos, persiste. Es muy molesto :-/

+1000.

Recibo este error cada vez (en un servidor aleatorio) solo con ejecución paralela (5, predeterminado):

ansible-playbook -i hosts -f 5 base_packages.yml

pero nunca con (-f 1):

 ansible-playbook -i hosts -f 1 base_packages.yml

@TomasCrhonek Acabo de probar con forks = 1 y me encontré con el mismo problema.

También ocurre cuando está limitado (-l) a un solo host (pero bifurcaciones = por defecto).

Ok, después de cientos de ejecuciones, finalmente obtengo este error con -f 1. Es muy raro.
(Debian Testing actualizado, ansible 2.0.0.2)

¿Alguien tiene una solución? Con el módulo de la ventana acoplable sucede todo el tiempo :(

Regresé a 1.9
No encontré una manera.

El lunes 15 de febrero de 2016 a las 18:30, leonty [email protected] escribió:

¿Alguien tiene una solución? Con el módulo de la ventana acoplable sucede todo el tiempo :(

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/ansible/ansible/issues/13876#issuecomment -184254466.

Tuve el mismo problema con RHEL 6.6 para máquinas de origen y destino y Ansible 2.0.0.2.
Pero, cuando desactivo ssh ControleMaster, en ansible.cfg, parece resolver este problema.

[ssh_connection]
ssh_args = -o ControlMaster=no

Dime si también te funciona ...

Regresó a ansible 2.0.0.2 e intentó reproducir la corrección de @vincentdelaunay .

Pero ya no he encontrado este error aquí. Parece que el problema fue solucionado por algún otro paquete durante un tiempo.

Mi sistema es Ubuntu 15.10
OpenSSH_6.9p1 Ubuntu-2ubuntu0.1, OpenSSL 1.0.2d 9 de julio de 2015
El kernel es 4.2.0-27-genérico

Espero que te ayude.

@vincentdelaunay Intento desactivar ssh ControleMaster, en ansible.cfg en ansible 2.0.0.2, ya no he encontrado este error aquí.
Pero el mismo entorno, en ansible 1.9.4, no necesita desactivar ssh ControleMaster, en ansible.cfg. Intenté usar -vvvv y contrast ansible 1.9.4 y 2.0.0.2 en el proceso de ejecución de los parámetros SSH, no se encontraron diferencias.

¿Si alguien sabe el motivo de la falla?

Veo este error de forma intermitente incluso con Paramiko. El comportamiento parece ser que es probable que cada tarea falle debido a este error con una probabilidad pequeña (~ 1-2%), pero para un libro de jugadas con cientos de tareas es seguro que ocurrirá.

Configurar ssh_args = -o ControlMaster=no no ayudó.

Kernel de Linux del servidor 4.4.0.

Sin embargo, no creo que sea realmente un error de Ansible. El siguiente script bash, aislado del patrón de acceso de Ansible, se reproduce de manera confiable para mí:

#!/bin/bash
set -e
HOST=YOUR_REMOTE_HOST_HERE
for i in `seq 1 100`; do
    TEMP=`ssh  -C -o ControlMaster=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -tt $HOST 'mkdir -p "$( echo $HOME/.ansible/tmp/ansible-tmp-1456012812.4-96487876295189 )" && echo "$( echo $HOME/.ansible/tmp/ansible-tmp-1456012812.4-96487876295189 )"'`
    WC=`echo "$TEMP" | wc -c | tr -d ' '`
    echo "$TEMP"
    echo "$WC"
    if [ "$WC" != "60" ]; then
        echo "error in $TEMP"
        exit 1
    fi
done

Por alguna razón, algunas de estas conexiones SSH misteriosamente no tienen salida.

He rastreado esto hasta que esté asociado con la bandera SSH -tt .

El siguiente parche me resuelve completamente el problema:

diff -r /Users/drew/Code/ansible-old/plugins/connection/ssh.py /Library/Python/2.7/site-packages/ansible/plugins/connection/ssh.py
572,575c572
<         if in_data:
<             cmd = self._build_command('ssh', self.host, cmd)
<         else:
<             cmd = self._build_command('ssh', '-tt', self.host, cmd)
---
>         cmd = self._build_command('ssh', self.host, cmd)
691c688
<         self._connected = False
\ No newline at end of file
---
>         self._connected = False

Al leer el historial aquí, parece que esta bandera se usa para solucionar un problema complejo que involucra la configuración de sudoer en algunos hosts.

No sufro por ningún problema que esta bandera esté aquí para resolver, pero sufro por el problema que crea, por lo que aplicar este parche es una solución muy eficaz para mí.

@drewcrawford big: +1: por bajar por la madriguera del conejo en este. Tengo curiosidad por saber más sobre el problema que el código sin parche está tratando de solucionar.

Después de cerrar un montón de conexiones con el objetivo, Ansible dejó de darme estos errores cuando se ejecutó. Ni -f1 ni el conjunto completo de --ssh-extra-args que deshabilitan el Control (https://groups.google.com/d/msg/ansible-project/FyK6au2O9KY/PS4yH6Y2AwAJ) parecían tener mucha influencia.

Tengo el mismo problema desde que actualicé algunos servidores del kernel 3.xa kernel 4.x. Puedo confirmar que ni -f1 ni el conjunto completo de --ssh-extra-args que deshabilitan el Control no ayudaron. Parcheé ansible como

La solución de @drewcrawford también funciona para mí. Tengo algunos libros de jugadas con cientos de tareas, lo que prácticamente garantizaba que alguna tarea arbitraria fallaría con este error. He estado usando la solución durante unos días sin problemas.

@drewcrawford Buen trabajo allí, por cierto, para cualquiera que considere que se mantendrá alejado de ir por debajo del kernel genérico 3.19.0-50 en Ubuntu con Docker, ya que encontrará muchos problemas con un error de aufs.

El error sigue ahí en ansible 2.0.1.0 (estable-2.0 61e9841e08)
Puedo confirmar que el parche de @drewcrawford funciona para mí.

Apliqué este parche de @bcoca
https://github.com/ansible/ansible/issues/14377#issuecomment -181909899

Lo que me resuelve el problema y tampoco rompe sudo

Con respecto al parche mencionado directamente anteriormente, si bien es probable que funcione para la mayoría de las personas, no es perfecto: https://github.com/ansible/ansible/issues/14377#issuecomment -190528876

Hay mucha información contradictoria en este tema. Podría haber varios problemas expuestos, pero debido a que es intermitente, es difícil saberlo con certeza. De acuerdo con la investigación de @drewcrawford , esto parecería estar relacionado de alguna manera con la asignación de pseudo terminal (tty) con ssh. Eso puede tener sentido con la información anterior en el error sobre alguna mala interacción entre ssh y los controladores tty del kernel de Linux.

Si eliminar -tt es todo lo que se necesita, la gente debería poder solucionar el problema con un cambio de archivo de configuración en el lado ansible y posiblemente un cambio de archivo de configuración a sudo en los hosts remotos. El condicional que ha encontrado en el complemento de conexión ssh se activa mediante la configuración de canalización en ansible.cfg. http://docs.ansible.com/ansible/intro_configuration.html#pipelining

Así que establezca pipelining = True en ansible.cfg y, si es necesario, elimine requiretty de su archivo de configuración / etc / sudoers para que sudo pueda funcionar.

Tenga en cuenta que hubo otro comentario incluso antes en el número que decía que activar y desactivar la canalización no afectaba el problema en absoluto. Por eso me pregunto si hay varios problemas que tienen el mismo síntoma. No hay forma de saberlo con certeza a menos que más personas intenten activar la canalización para ver si afecta la frecuencia con la que tienen este problema de alguna manera.

El condicional que ha encontrado en el complemento de conexión ssh se activa mediante la configuración de canalización en ansible.cfg

He tenido lo siguiente en mi ansible.cfg desde la instalación:

[ssh_connection]
pipelining=True

No resolvió el problema. La única solución confiable para mi caso fue deshabilitar -tt mediante un parche. Hay alguna otra forma de terminar en el caso -tt con el archivo de configuración anterior.

Podría haber varios problemas expuestos, pero debido a que es intermitente, es difícil saberlo con certeza.

El script bash en este comentario no es intermitente. La parte intermitente es que los libros de jugadas breves de Ansible pueden no realizar pruebas de estrés tan a fondo como ese script bash. Pero el script en sí debería poder diagnosticar de manera confiable el problema particular que sufro.

Si alguien puede informar que sufre el mismo error sin fallar ese script bash, entonces sabríamos que hay varios problemas.

¿Pipelining = True produce una tasa de falla más baja?

Si ejecuta con pipelining = True y -vvvv, ¿ve que la última conexión antes del error usa -tt o no? ¿Utiliza canalización o no?

Y tiene razón en que solo los módulos pasan por la canalización, por lo que es posible que estemos fallando al ejecutar un comando de shell remoto en lugar de un módulo ... pero esperaría que veamos alguna indicación de eso en las respuestas a mi preguntas anteriores.

Ah, y probablemente una pregunta más, ¿tiene requiretty = True en sus sudoers remotos? Creo que lo probé hace unos meses y todavía no era seguro eliminar -tt si requiretty está activado, pero un ejemplo contrario sería maravilloso.

Lo solucioné al tener un contenedor ssh en PATH en mi host. Utilizo un archivo MAKE para iniciar ansible-playbook, y antepongo $ PWD / .ssh-hack / al PATH antes de ejecutar ansible-playbook.

.ssh-hack / ssh es el siguiente script:

#!/usr/bin/perl
use strict;
use warnings;
my @command;
foreach my $component (@ARGV)
{
    next if $component eq '-tt';
    push(<strong i="7">@command</strong>,$component);
}
exec('/usr/bin/ssh',@command);

Después de agregar este truco, este problema ha desaparecido.

@zerodogg¿Tienes requiretty en sudoers en alguna parte? Si está configurado y está utilizando de forma segura un código que elimina -tt, podemos revisar si esa es una posibilidad.

Reabriendo ante la posibilidad de que podamos encontrar una solución de código a este problema. Sin embargo, no podemos hacer promesas sobre la viabilidad de esa posibilidad hasta que recopilemos más información.

@abadger Ninguno de mis hosts tiene un conjunto requiretty (sudoers de Debian y Arch predeterminados). Quizás si eliminar -tt de forma predeterminada no es factible, podría convertirse en una opción de host como ansible_python_interpreter ? ansible_no_force_tty=BOOL o algo así, al menos permitiría trabajar sin un truco.

@drewcrawford Me pregunto si esto está relacionado con alguna entrada de basura que cruza la línea y se repite. Si antepone echo -n '' | a su comando ssh, ¿aún falla de manera confiable?

Además, realmente me gustaría que alguien que pueda reproducir esto lo ejecute con ANSIBLE_DEBUG=1 y publique el resultado completo (la esencia sería preferible a pegarla aquí).

@drewcrawford por cierto, seguimos pidiéndote que

Aquí hay un script equivalente al de @drewcrawford , usando la API interna:

 desde ansible.utils.display import Display
 display = Display (verbosidad = 3)
 desde ansible.playbook.play_context importar PlayContext
 desde ansible.plugins importar connection_loader
 p = PlayContext ()
 p.remote_addr = '<SU ANFITRIÓN AQUÍ>'
 p.ssh_args = '-o ControlMaster = no'
 # p.verbosity = 4
 ssh = connection_loader.get ('ssh', p, Ninguno)
 para i en el rango (1000):
 res = ssh.exec_command ('mkdir -p "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1456012812.4-96487876295189)" && echo "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1456012812.4 -96487876295189) "')
 if res [1] .strip ()! = '/path/to/users/home/.ansible/tmp/ansible-tmp-1456012812.4-96487876295189':
 imprimir ("FALLIDO")
 romper
 imprimir (res)
 ssh.exec_command ('rm -rf $ HOME / .ansible / tmp / ansible-tmp-1456012812.4-96487876295189')

Entonces, primero déjenme decirles que les creo completamente a los reporteros de este error, en que algo está sucediendo aquí. Hay demasiadas personas que informan esto para descartarlo. Sin embargo, varios de nosotros hemos intentado reproducir esto durante una hora en una variedad de configuraciones y aún no hemos visto la falla informada.

Entonces, en este punto, realmente necesitamos una forma definitiva de reproducir esto. Si alguien pudiera usar mi script anterior o la siguiente variación en un conjunto de instancias EC2 y proporcionarnos los ID de AMI relevantes para ayudar a depurar esto, realmente lo agradeceríamos.

 tiempo de importación
 desde ansible.utils.display import Display
 display = Display (verbosidad = 3)
 desde ansible.playbook.play_context importar PlayContext
 desde ansible.plugins importar connection_loader
 p = PlayContext ()
 p.remote_addr = '<SU ANFITRIÓN AQUÍ>'
 p.ssh_args = '-o ControlMaster = auto -o ControlPersist = 3'
 # p.verbosity = 4
 ssh = connection_loader.get ('ssh', p, Ninguno)
 para i en el rango (1000):
 res = ssh.exec_command ('mkdir -p "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1456012812.4-96487876295189)" && echo "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1456012812.4 -96487876295189) "')
 if res [1] .strip ()! = '/ <SU CASA REMOTA AQUÍ> /. ansible / tmp / ansible-tmp-1456012812.4-96487876295189':
 imprimir ("FALLIDO")
 romper
 imprimir (res)
 ssh.exec_command ('rm -rf $ HOME / .ansible / tmp / ansible-tmp-1456012812.4-96487876295189')
 hora de dormir (5)

La principal diferencia con este script es que usa ControlPersist, pero establece el tiempo de espera y duerme de tal manera que se crea una nueva conexión persistente cada vez.

Ok, en realidad puedo reproducir esto de manera consistente contra esta imagen de la ventana acoplable: chrismeyers/centos6 , usando el siguiente script (que usa los métodos de complemento de acción de manera más directa para crear la temperatura remota):

 #! / usr / bin / python
 desde ansible.utils.display import Display
 display = Display (verbosidad = 3)
 desde ansible.playbook.play_context importar PlayContext
 desde ansible.plugins importar action_loader, connection_loader
 p = PlayContext ()
 p.remote_addr = '172.17.0.2'
 p.remote_user = 'root'
 p.password = 'docker.io'
 p.pipelining = Verdadero
 ssh = connection_loader.get ('ssh', p, Ninguno)
 handler = action_loader.get ('normal', Ninguno, ssh, p, Ninguno, Ninguno, Ninguno)
 mientras es cierto:
 tmp = manejador._make_tmp_path ()
 imprimir (tmp)
 handler._remove_tmp_path (tmp)

woot!

Así que algo más divertido con este error: ejecutar sshd en el contenedor anterior con -ddd para intentar obtener información de depuración sobre el lado remoto no falla. He estado ejecutando el script anterior en su contra durante más de 11 horas sin desencadenar el error.

Mi pila de software:

• Versión de CentOS Linux 7.2.1511 (Core)
• núcleo: 4.5.0-1.el7.elrepo.x86_64
• sshd: openssh-6.6.1p1-23.el7_2.x86_64

Este error siempre aparece al iniciar procesos pesados ​​(contenedores docker o java) en aws t2.micro y desaparece con t2.large.

Parece que el sistema es inestable al aumentar la carga.

Hmm, ¿carrera de descarga de búfer con el canal de conexión múltiple cerrado? ¿Qué pasa si colgamos un pequeño sueño al final de los comandos?

@ederrm , esa es una información realmente útil, creo que la mayoría de las

Experimentar exactamente el mismo comportamiento que se mencionó anteriormente.

$ ansible --version
ansible 2.0.1.0
  config file =
  configured module search path = Default w/o overrides

[16:50:27][jenkins@master51_192.168.121.200:][~]
$ ansible -vvvv nat21.host.ee --private-key /var/lib/jenkins/.ssh/id_rsa -u root -m ping
No config file found; using defaults
Loaded callback minimal of type stdout, v2.0
<nat21.host.ee> ESTABLISH SSH CONNECTION FOR USER: root
<nat21.host.ee> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o 'IdentityFile="/var/lib/jenkins/.ssh/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/var/lib/jenkins/.ansible/cp/ansible-ssh-%h-%p-%r -tt nat21.host.ee '/bin/sh -c '"'"'mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1459864230.34-240286631163976 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1459864230.34-240286631163976 `"'"'"''
nat21.host.ee | FAILED! => {
    "failed": true,
    "msg": "failed to resolve remote temporary directory from ansible-tmp-1459864230.34-240286631163976: `mkdir -p \"` echo $HOME/.ansible/tmp/ansible-tmp-1459864230.34-240286631163976 `\" && echo \"` echo $HOME/.ansible/tmp/ansible-tmp-1459864230.34-240286631163976 `\"` returned empty string"
}
[16:50:42][jenkins@master51_192.168.121.200:][~]
$ ansible -vvvv nat21.host.ee --private-key /var/lib/jenkins/.ssh/id_rsa -u root -m ping
No config file found; using defaults
Loaded callback minimal of type stdout, v2.0
<nat21.host.ee> ESTABLISH SSH CONNECTION FOR USER: root
<nat21.host.ee> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o 'IdentityFile="/var/lib/jenkins/.ssh/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/var/lib/jenkins/.ansible/cp/ansible-ssh-%h-%p-%r -tt nat21.host.ee '/bin/sh -c '"'"'mkdir -p "` echo $HOME/.ansible/tmp/ansible-tmp-1459864243.6-2450988655105 `" && echo "` echo $HOME/.ansible/tmp/ansible-tmp-1459864243.6-2450988655105 `"'"'"''
<nat21.host.ee> PUT /tmp/tmprOjXcP TO /root/.ansible/tmp/ansible-tmp-1459864243.6-2450988655105/ping
<nat21.host.ee> SSH: EXEC sftp -b - -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o 'IdentityFile="/var/lib/jenkins/.ssh/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/var/lib/jenkins/.ansible/cp/ansible-ssh-%h-%p-%r '[nat21.host.ee]'
<nat21.host.ee> ESTABLISH SSH CONNECTION FOR USER: root
<nat21.host.ee> SSH: EXEC ssh -C -vvv -o ControlMaster=auto -o ControlPersist=60s -o Port=22 -o 'IdentityFile="/var/lib/jenkins/.ssh/id_rsa"' -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=10 -o ControlPath=/var/lib/jenkins/.ansible/cp/ansible-ssh-%h-%p-%r -tt nat21.host.ee '/bin/sh -c '"'"'LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 /usr/bin/python /root/.ansible/tmp/ansible-tmp-1459864243.6-2450988655105/ping; rm -rf "/root/.ansible/tmp/ansible-tmp-1459864243.6-2450988655105/" > /dev/null 2>&1'"'"''
nat21.host.ee | SUCCESS => {
    "changed": false,
    "invocation": {
        "module_args": {
            "data": null
        },
        "module_name": "ping"
    },
    "ping": "pong"
}

Como puede ver, la ejecución del ping en el primer intento falló, ejecutar de nuevo exactamente el mismo comando por segunda vez funcionó bien. ¿Tiene algo que ver con la conexión persistente ssh?

editar:

El problema se resolvió agregando:

...
[ssh_connection]
ssh_args = -o ControlMaster = no
...

En ansible.cfg

Apenas puedo ejecutar mi libro de jugadas por completo, a menudo también falla en la "configuración". Además, los controladores no se ejecutarán si se realizó un cambio y luego se cancelará el ansible.

grep ControlMaster etc / ansible.cfg
ssh_args = -o ControlMaster = no -o ControlPersist = 60 s
ansible-playbook buildbot-slaves.yml --limit = juschinka.home
fatal: [juschinka.home]: ¡FALLÓ! => {"failed": true, "msg": "no se pudo resolver el directorio temporal remoto de ansible-tmp-1460312056.02-264065629966800: mkdir -p \" echo $ HOME / .ansible / tmp / ansible-tmp-1460312056.02- 264065629966800 \" && echo \" echo $ HOME / .ansible / tmp / ansible-tmp-1460312056.02-264065629966800 \" devuelto cadena vacía "}

Además, no tengo mejor suerte sin openssh, paramiko parece no funcionar también:

ansible-playbook -c paramiko buildbot-slaves.yml --limit = juschinka.home
fatal: [juschinka.home]: ¡FALLÓ! => {"failed": true, "msg": "no se pudo resolver el directorio temporal remoto de ansible-tmp-1460312119.01-155638274935319: mkdir -p \" echo $ HOME / .ansible / tmp / ansible-tmp-1460312119.01- 155638274935319 \" && echo \" echo $ HOME / .ansible / tmp / ansible-tmp-1460312119.01-155638274935319 \" devuelto cadena vacía "}

Me di cuenta de esto por primera vez, una vez que comencé a trabajar en mi máquina de escritorio más rápida, la computadora portátil no lo hizo, aunque el ansible de Debian instalado en la computadora portátil no lo hizo. Lo interesante es que esto recién comenzó hoy, trabajé toda la semana en esta configuración sin ningún problema y que solo una máquina se ve muy afectada y una con menos frecuencia, pero ambas son Debian Stretch (Pruebas). Hago ansible-playbook desde ambas máquinas. No importa en cuál ejecute el libro de jugadas, local y remoto, ambos pueden fallar. Dos máquinas estables de Debian prácticamente nunca se ven afectadas.

Lo que no obtuve de la discusión, si se usa "sudo", incluso si estoy usando remote_user = root. Todavía no limpié la configuración de sudo. Esto definitivamente podría ser diferente.

He estado usando ansible sin encontrarme con este problema durante bastante tiempo. Hoy temprano, comencé a cargar un archivo grande en otro dispositivo (no relacionado), y comencé a encontrarme constantemente con este problema, generalmente en las primeras 3 o 4 etapas de mi libro de jugadas. En mi caso, configurar pipelining = True evitó que el problema se repitiera con tanta frecuencia, pero aún así sucedió en un comando que usaba -tt:

ssh -C -vvv -o ControlMaster = auto -o ControlPersist = 60s -o StrictHostKeyChecking = no -o Puerto = 22 -o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey -o PasswordAuthentication = no -o User = ubuntu -o ConnectTimeout = 10 -o ControlPath = / Users / crschmidt / .ansible / cp / ansible-ssh-% h-% p-% r -tt 66.228.35.122 '(umask 22 && mkdir - p "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1460329511.62-77852023686217)" && echo "$ (echo $ HOME / .ansible / tmp / ansible-tmp-1460329511.62-77852023686217)") '

Creo que esto apoya la idea de que se trata de una condición de carrera; en mi caso, posiblemente se hizo más común debido a las restricciones de ancho de banda ascendente que reducen mi ancho de banda efectivo para ansible.

Pensé que mencionaría esto en caso de que estos datos adicionales ayudaran.

crschmidt-macbookair: ~ crschmidt $ ansible-playbook --version
ansible-playbook 2.0.0.2

Sugeriría que más personas confirmen si los cambios que @drewcrawford publicó anteriormente funcionan para ellos o no, en mi caso me han permitido evitar este problema de manera confiable.

Si más personas pueden confirmar si ese cambio soluciona sus problemas, entonces podría ser más fácil conseguir algo aceptado en las fases iniciales que lo presente como una opción o según sea apropiado.

@cewood buena idea.
Puedo confirmar que este parche parece solucionar el problema.
En mi caso, Playbooks apenas pasó por completo usando solo una bifurcación (y empeoró con varias bifurcaciones). Con el parche aplicado, funciona con tantas bifurcaciones como hosts (virtuales) (en un nodo compartido). ¡Gracias!

solucionó el problema para mí, gracias @drewcrawford

También confirmo que el parche de @drewcrawford soluciona el problema aquí.

Hice el cambio por @drewcrawford manualmente (agregué un "o Verdadero") a la condición, y solucionó el problema por completo. Creo que eso también confirma su parche.

Así que creo que probablemente deberíamos restringir la eliminación de -tt a situaciones en las que estamos ejecutando comandos de shell sin procesar, por ejemplo, el comando mkdir. La opción sudoable creo que abarcaría esto, ya que se establece en falso en esta situación:

 cmd = self._connection._shell.mkdtemp (archivo base, use_system_tmp, tmp_mode)
 resultado = self._low_level_execute_command (cmd, sudoable = False)

Entonces el parche de @drewcraford se convertiría en:

 diff --git a / lib / ansible / plugins / connection / ssh.py b / lib / ansible / plugins / connection / ssh.py
 índice dcea2e5..b03b15f 100644
 --- a / lib / ansible / plugins / connection / ssh.py
 +++ b / lib / ansible / plugins / connection / ssh.py
 @@ -559,11 +559,12 @@ clase Conexión (ConnectionBase):
 # python modo interactivo, pero los módulos no son compatibles con el
 # modo interactivo ("sangría inesperada" principalmente debido a líneas vacías)

 - si in_data:
 - cmd = self._build_command ('ssh', self.host, cmd)
 + si no es in_data y sudoable:
 + args = ('ssh', '-tt', self.host, cmd)
 más:
 - cmd = self._build_command ('ssh', '-tt', self.host, cmd)
 + args = ('ssh', self.host, cmd)

 + cmd = self._build_command (* argumentos)
 (código de retorno, stdout, stderr) = self._run (cmd, in_data, sudoable = sudoable)

 return (código de retorno, stdout, stderr)

Y una prueba de muestra:

 # ANSIBLE_SSH_PIPELINING = 0 ansible -m ping awxlocal -vvv -c ssh
 Usando /etc/ansible/ansible.cfg como archivo de configuración
 <192.168.122.100> ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: prueba
 <192.168.122.100> SSH: EXEC ssh -C -q -o ControlMaster = auto -o ControlPersist = 60s -o ControlPath = / tmp / ansible-ssh-% h-% p-% r -o Port = 22 -o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey -o PasswordAuthentication = no -o Usuario = probando -o ConnectTimeout = 10192.168.122.100 '/ bin / sh -c' "'"' ( umask 77 && mkdir -p "` echo $ HOME / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 `" && echo "` echo $ HOME / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 `") ' "'"' '
 <192.168.122.100> PUT / tmp / tmp2GYPZG TO / var / lib / testing home / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 / ping
 <192.168.122.100> SSH: EXEC scp -C -o ControlMaster = auto -o ControlPersist = 60s -o ControlPath = / tmp / ansible-ssh-% h-% p-% r -o Puerto = 22 -o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey -o PasswordAuthentication = no -o Usuario = probando -o ConnectTimeout = 10 / tmp / tmp2GYPZG '[192.168.122.100]:' "'"' / var / lib / testing home / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 / ping '"'" ''
 <192.168.122.100> ESTABLEZCA LA CONEXIÓN SSH PARA EL USUARIO: prueba
 <192.168.122.100> SSH: EXEC ssh -C -q -o ControlMaster = auto -o ControlPersist = 60s -o ControlPath = / tmp / ansible-ssh-% h-% p-% r -o Port = 22 -o KbdInteractiveAuthentication = no -o PreferredAuthentications = gssapi-with-mic, gssapi-keyex, hostbased, publickey -o PasswordAuthentication = no -o Usuario = probando -o ConnectTimeout = 10 -tt 192.168.122.100 '/ bin / sh -c' "'" 'LANG = en_US.UTF-8 LC_ALL = en_US.UTF-8 LC_MESSAGES = en_US.UTF-8 / usr / bin / python' "'"' "'"' "'"' "'"' / var / lib / probando home / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 / ping '"'" '"'" '"'" '"'" '; rm -rf "/ var / lib / testing home / .ansible / tmp / ansible-tmp-1460397005.14-70049559304095 /"> / dev / null 2> & 1 '"'" ''
 awxlocal | ÉXITO => {
 "cambiado": falso, 
 "invocación": {
 "module_args": {
 "datos": nulo
 }, 
 "nombre_módulo": "ping"
 }, 
 "ping pong"
 }

^ Puede ver en lo anterior, que la primera línea EXEC no usa -tt , sin embargo las dos siguientes sí lo hacen.

¿Puede alguien que tenga este problema probar el parche anterior para asegurarse de que resuelve el problema de la misma manera que el original de Drew?

@cewood El parche de @drewcrawford funcionó para mí. He estado ejecutando esto durante una semana sin errores.

FWIW, mi parche anterior parece resolver el problema en mi configuración de reproducción, si alguien más quiere verificar:
1) Docker ejecutar -d chrismeyers / centos6
2) ejecute mi script de Python arriba (ejecutar varias instancias de él puede acelerar una falla)

Con lo anterior, normalmente veo una falla en <3 minutos. Con mi parche, los scripts se ejecutaron durante más de 30 minutos sin fallas. El problema que tengo aquí es que no siempre falla, el error es tan intermitente que tengo problemas para decir que está definitivamente arreglado a pesar de que mi script de prueba se está ejecutando durante tanto tiempo.

Seguí adelante y me fusioné en el parche que publiqué arriba. Esto también se incluirá en la próxima versión.

Si continúa viendo algún problema relacionado con este problema, o si tiene más preguntas, avísenos pasando por una de las dos listas de correo, según corresponda:

• https://groups.google.com/forum/#!forum/ansible -project - para preguntas, sugerencias y trucos de los usuarios
• https://groups.google.com/forum/#!forum/ansible -devel - para estrategias, planificación futura y preguntas sobre la escritura de código

Debido a que este proyecto es muy activo, es poco probable que veamos comentarios sobre tickets cerrados, pero la lista de correo es una excelente manera de hacer preguntas o publicar si cree que este problema en particular no está resuelto.

¡Gracias!

Para agregar un punto de datos más que confirma que había un error específico en la opción -tt , experimenté estos mismos síntomas en Ansible 1.5.4; Pude reproducir el error de manera efectiva el 100% del tiempo en al menos una tarea en un libro de jugadas grande y el truco de script de Perl que @zerodogg publicó solucionó el problema de inmediato.

@ jimi-c ¿Tiene una fecha de lanzamiento del parche? Estoy experimentando este problema con demasiada frecuencia para mi gusto, lo que causa problemas con nuestras implementaciones.

@macnibblet esto estará en 2.0.2 y 2.1.

2.0.2 debería estar disponible muy pronto (hoy en día), 2.1 probablemente saldrá a principios de mayo en este momento.

Reabrir, ya que todavía creemos que eliminar -tt es una solución alternativa en lugar de la respuesta final a este error.

También he tenido este problema, especialmente al ejecutar libros de jugadas con muchas tareas. Esto también provocó que get_url (o wget con el módulo de comando) fallara al descargar archivos más grandes. Dice que la descarga está completa, pero no se ha descargado todo el archivo. Actualicé a 2.0.2 y el problema parece haber desaparecido. ¡Gracias! :)

Después de la actualización 2.0.1 -> 2.0.2 apareció este problema (no estaba presente en .1)
Pasos para reproducir:
ansible -vvvv todo -i mongo, -c docker -m ping

Respuesta en .2:
Usando… / ansible.cfg como archivo de configuración
Devolución de llamada cargada mínima de tipo stdout, v2.0
ESTABLEZCA LA CONEXIÓN DOCKER PARA EL USUARIO: Ninguna
EXEC ['/ usr / local / bin / docker', 'exec', '-u', Ninguno, '-i', 'mongo', '/ bin / sh', '-c', u "/ bin / sh -c 'LANG = ru_RU.UTF-8 LC_ALL = ru_RU.UTF-8 LC_MESSAGES = ru_RU.UTF-8 / usr / bin / python' "]
mongo | ¡HA FALLADO! => {
"cambiado": falso,
"fallido": cierto,
"invocación": {
"nombre_módulo": "ping"
},
"module_stderr": "",
"module_stdout": "",
"msg": "FALLO DEL MÓDULO",
"analizado": falso
}

Definitivamente todavía en 2.0.2. Estoy ejecutando Packer para crear una máquina virtual Ubuntu 14.04 desde cero (no es ideal, pero es lo que usamos) y uso el aprovisionador ansible al instalar el sistema operativo para ejecutar mi libro de estrategias de más de 200 tareas. Pensé que era solo yo debido a la configuración extraña y al propio Packer que es beta-ish (la versión 0.10.0 es la última). Pero definitivamente he visto esto en ansible 2.0.1 y 2.0.2.

Sin embargo, no he probado ninguno de los scripts o soluciones alternativas, así que no tengo nada que añadir al respecto. ¡Lo siento!

Sí, también tengo este problema (con 2.0.2) ...

Experimenté esto con Ansible 2.0.1 conectándose a un host Ubuntu 16.04 (pero no al conectarse a hosts 14.04). Se actualizó a 2.0.2 y aún no se ha vuelto a producir.

Experimenté este problema con ansible 2.0.2. Estoy ejecutando ansible contra una VM chef / centos-6.6 girada a través de vagrant. No he probado la solución alternativa, ya que tampoco estoy seguro de si es una solución válida.

EDITAR: Probé la solución alternativa y todavía da el mismo error.

2.0.2.0 arregló esto por mí

Todavía veo esto en 2.0.2.0 al presionar los contenedores Docker para Mac Beta.

La configuración de ansible_user = root en el inventario me ha solucionado este problema.

No he visto este problema con 2.0.2.0 en absoluto. Anteriormente era muy frecuente.

Solía ​​ver este problema mucho antes de actualizar a 2.0.2.0, parece que se solucionó después de la actualización.

Creé un entorno para reproducir el problema @ https://github.com/dregin/ansible-docker-connector
¿Pueden otras personas verificar si ven el mismo comportamiento?

Aún veo esto después de una actualización de 1.9.xa 2.0.2.

En ansible.cfg había un gathering = smart , deshabilitado esta configuración lo arregló para mí. http://docs.ansible.com/ansible/intro_configuration.html#sts = reuniendo% C2% B6

Destino: Debian 7
Anfitrión: CentOS 6

Viendo el error con ansible 2.0.2.0 con contenedores Docker (target = ubuntu 14.04 && host = ubuntu 14.04)
@dregin 's solución, estableciendo ansible_user = raíz parece cambiar el tema desde 'siempre' a 'intermitente'.
Así que sigo teniendo problemas :(

Este problema me desaparece si configuro lo siguiente en ansible.cfg :

[ssh_connection]
pipelining = True

Anfitrión: Ubuntu 16.04 i386 (paquete de SO ansible versión 2.0.0.2-2)
Destino: Varios Debian (7/8) / Ubuntu (principalmente 16.04).

@ tim-seoss que se debe al hecho de que el modo de canalización también deshabilita el uso de -tt (ya que el intérprete de Python entra en modo interactivo si hay un pty).

Solo aquí para decir +1

• Ansible 2.0.1
• Aprovisionamiento de OSX 10.11 Ubuntu 16.04

Desde mi servidor Ubuntu 16.04 MaaS, con Ansible de los repositorios de Ubuntu, veo este problema al azar, mientras ejecuto Ansible contra los nodos MaaS (solo 2 por ahora) ...: - /

Tiene este aspecto:

[ssh_connection]
ssh_args = -o ControlMaster=no

... ayuda ... intentaré más ...

EDITADO (13 de junio): No funcionó ... :(

El mismo problema aqui.
Solución Bazooka: en el host remoto rm -rf /tmp/* ~/.ansible/*

rm -rf / tmp / *

Por lo general, es una mala idea si su control remoto hace algo más que ejecutar tareas de Ansible (lo que es muy probable).

rm -rf ~/.ansible/tmp en la máquina remota (como root) hizo el trabajo por mí (servidor ansible: Ubuntu 16.10, ansible 2.0.0.2)

No estoy seguro de si es solo una coincidencia, pero vi este problema con mucha frecuencia en 16.04, pero casi siempre (¿tal vez incluso solo?) Al utilizar el módulo command . Cuando cambié a una versión equivalente file módulo de mkdir -p , dejé de ver este problema. FWIW Borré todos los directorios .ansible/ (en los hosts de destino), pero eso no me resolvió.

Encuentro lo mismo en ubuntu 16.04, pero agregar --ssh-extra-args = "- o ControlMaster = no -o ControlPath = none -o ControlPersist = no" parece ayudar.

@mspanc : tenga cuidado, si está usando ssh_extra_args (y no ssh_args), está mezclando sus argumentos ControlPersist con los generados por defecto, por lo que el comportamiento de OpenSSH podría ser, digamos, "indefinido"?

De todos modos, esto solo pareció solucionar el problema. Tuve que usar otro ubuntu
14.04 máquina para ejecutar correctamente mis scripts ansible.

Lo mismo aquí ansible 2.1.2.0 (estable-2.1 559fcbe531), objetivo rhel 7.2
Lo curioso es que cuando no funciona, se ejecuta con "-vvv". Y un poco más tarde, tan pronto como deja de funcionar con "-vvv", vuelve a funcionar con normalidad sin ser detallado.

El bugzilla de Openssh mencionado anteriormente (https://bugzilla.mindrot.org/show_bug.cgi?id=2492) tiene este comentario:

La solución ahora se ha incorporado en los siguientes núcleos principales de Linux: 4.1.26, 4.4.12, 4.5.6, 4.6.1 y el recién lanzado 4.7.

y enlaces a esta confirmación: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa

Muchas distribuciones de Linux a largo plazo (RHEL, Ubuntu-LTS, etc.) están ejecutando kernels más antiguos. Tendría que auditar los parches que aplicaron al kernel para averiguar si han transferido la corrección a sus paquetes.

¿Alguien tiene alguna pista sobre este problema? Probamos todas las soluciones antes mencionadas (excepto actualizar el kernel), pero ninguna funcionó. Construimos una buena infraestructura de instalación usando ansible. Pero este pequeño problema nos está matando. Siempre que ejecutamos el comando ansible-playbook, el primero arroja este mensaje de falla. Sobre todo, el segundo funciona. Además, durante la instalación, vemos el mismo problema en puntos aleatorios.
Host & Targets son CentOS 6.6 y estamos usando Ansible 2.1.2.
Regresar a 1.9.4 está resolviendo el problema, sin embargo, estamos perdiendo muchas características interesantes que ya hemos implementado.
Se agradecería cualquier ayuda o idea.
Gracias

Probamos todas las soluciones mencionadas anteriormente (excepto actualizar el kernel).

¿Alguna razón por la que no puede actualizar el kernel?

Es muy difícil persuadir a la gente para que actualice el kernel. Desde el
kernel se basa en este sistema. (La única excusa razonable podría ser
Error de vaca sucia. )

El 31 de octubre de 2016 a las 15:41, "joernheissler" [email protected] escribió:

Probamos todas las soluciones antes mencionadas (excepto actualizar el kernel
sí mismo).

¿Alguna razón por la que no puede actualizar el kernel?

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/13876#issuecomment -257283301,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APNso4aGfA1x4MeZ9hUQr9ih12kMpYLtks5q5eHngaJpZM4HEsbd
.

Hola,

Solo para que conste, tuve este problema con un controlador que tiene CentOS 6.6 (esta versión menor). La actualización de ssh de este servidor hace que vuelva a funcionar. Encontré esta solución más fácil que actualizar el kernel ;-)

Saludos,

JYL

Hola,
Gracias por la respuesta. Aunque ya he actualizado mi servidor ansible
a Centos 6.8, lo intentaré en otro servidor ansible.
Serdar

El 21 de diciembre de 2016 a las 11:47 a. M., "Jean-Yves LENHOF" [email protected]
escribió:

Hola,

Solo para que conste, tuve este problema con un controlador que tiene CentOS
6.6 (esta versión menor). La actualización de ssh de este servidor hace que vuelva a funcionar.
Encontré esta solución más fácil que actualizar el kernel ;-)

Saludos,

JYL

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/ansible/ansible/issues/13876#issuecomment-268468483 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/APNsowBfyc2t4YLFhvdIl9jIxmKA6D2xks5rKOesgaJpZM4HEsbd
.

Hola,

Recibo el mismo error con CentOS7.
Versión Ansible

ansible 2.2.1.0

@chinatree ¡Saludos! Gracias por tomarse el tiempo para abrir este problema. Para que la comunidad maneje su problema de manera efectiva, necesitamos un poco más de información.

Estos son los elementos que no pudimos encontrar en su descripción:

• Tipo de problema
• versión ansible
• Nombre del componente

Establezca la descripción de este problema con esta plantilla:
https://raw.githubusercontent.com/ansible/ansible/devel/.github/ISSUE_TEMPLATE.md

haga clic aquí para obtener ayuda con el bot

También sigo teniendo este problema con regularidad, principalmente al configurar cajas empacadoras. Estoy usando Ansible 2.3.0 en Ubuntu 16.10.

@JoelFeiner Solo por interés, ¿qué versión de kernel de OS / Linux está ejecutando su nodo administrado?

@joernheissler : la salida de uname -a en la máquina que ejecuta Ansible está debajo

Linux ********* 4.8.0-52-generic #55-Ubuntu SMP Fri Apr 28 13:28:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Las máquinas virtuales ejecutan Centos 7, y un uname -a en una de ellas se ve así:

Linux localhost.localdomain 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

@JoelFeiner Entonces está ejecutando un kernel de 4 años que no incluye la solución (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id = 0f40fbbcc34e093255a2b2d70b6b0fb48c3f39aa).

Por cierto, no he visto este error en mucho tiempo, desde que actualicé los núcleos en mis servidores.

¿Por qué este error no está cerrado de todos modos? No es un problema de ansible.

Obtuve el visto bueno para usar un kernel más nuevo de elrepo. Con suerte, eso solucionará el problema entonces.

LOL: Me he topado con una implementación de suspensión que falla en sleep 0 , como en:

$ sleep 0; echo $?
1
$ sleep 1; echo $?
0

Hackear plugins/action/__init__.py para agregar "{ sleep 0 || :; }" lugar de "sleep 0" ayuda por ahora (usando el shell Bourne solo aquí, no estoy seguro de cómo podría funcionar eso por csh ).

Sin embargo, hay otra implementación de suspensión disponible en esa máquina, pero la especificación de un / ruta / a / suspensión explícita parece no ser compatible a partir de ansible-2.2.2.0 ...

Para los registros: esto es / usr / bin / sleep en Interix (una capa POSIX para Windows, abandonada mientras tanto, pero sigue siendo parte de mi infra aquí).

@joernheissler : desafortunadamente, esto me sucedió nuevamente en el kernel 4.4.69. Este kernel contiene la confirmación con la corrección.

¿Puede armar un caso de prueba completo para que otros puedan reproducirlo?

Es un error muy intermitente que puede ocurrir con cualquier tarea, así que no creo que sea factible.

JoelFeiner, intente actualizar ssh como está escrito en el hilo ...

@jylenhofgfi No veo nada en este hilo sobre la actualización de SSH, solo el kernel. Qué versión estás usando? ¿En los hosts remotos o locales?

En su mayoría, el ajuste ControlMaster = no debería solucionar este problema. Debe verificar su versión de openssh. desde la versión 5.1, openssh comenzó a admitir multiplexación, pero funciona muy bien en la versión 5.6. Así que sugiero actualizar su servidor openssh a 5.6 o superior.

Notas de la versión: https://www.openssh.com/txt/release-5.1

@chinatree No ha respondido a las solicitudes de información sobre este tema, por lo que asumiremos que ya no le afecta. Si aún está interesado en esto, cree un nuevo problema con la información solicitada.

haga clic aquí para obtener ayuda con el bot

reapertura hasta que se fusione https://github.com/ansible/ansible/issues/31022 .

! need_info

resolve_by_pr https://github.com/ansible/ansible/issues/31022

bot_skip

Para cualquiera que intente experimentar con este problema en desarrollo, ahora tenemos una opción de configuración use_tty que puede deshabilitar el complemento de conexión para que no agregue "-tt" sin tener que piratear el código.

https://github.com/ansible/ansible/commit/218987eac1eb9a5671f996d2887dcca349199e51

El problema original descrito en este problema con la resolución del directorio temporal debería haber sido resuelto por https://github.com/ansible/ansible/pull/31677.