Ansible: apt: update_cache = yes fallando en ansible 1.3 (?)

¿Cómo estás invocando ansible-playbook, con -K? Hubo un cambio en 1.3 que indica que sudo debe especificarse explícitamente ya que el indicador -K no hará que las tareas usen sudo implícitamente.

Sí, estaba usando -K y usando sudo explícitamente en la mayoría de los lugares, pero no en
este caso específico. Entonces, ese es probablemente el isse.

Muy respetuosamente,

Dan CaJacob

El martes, 17 de septiembre de 2013 a las 4:23 p.m., James Cammarata
[email protected]ó :

¿Cómo estás invocando ansible-playbook, con -K? Hubo un cambio en 1.3
que sudo debe especificarse explícitamente ya que el indicador -K no hará tareas
use sudo implícitamente.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Ok, te dejaré confirmar eso y si es así cerraremos esto. ¡Gracias!

Lo haré. ¡Gracias!

Muy respetuosamente,

Dan CaJacob

El martes, 17 de septiembre de 2013 a las 4:27 p.m., James Cammarata
[email protected]ó :

Ok, te dejaré confirmar eso y si es así cerraremos esto. ¡Gracias!

-
Responda a este correo electrónico directamente o véalo en Gi
.

¿Algún seguimiento a esto?

Continuando y cerrando esto, si aún tiene un problema, háganoslo saber. ¡Gracias!

También me encuentro con este problema. Ejecutando 1.3.2 pero no tengo referencias de versiones antiguas.

Al usar -K, obtengo otro error: la conexión ssh se cerró esperando la solicitud de contraseña de sudo.

Al final, necesito ejecutar esto no en modo interactivo, por lo que -K no puede ser la respuesta final.

Más detalles: ejecución manual: host1. *** es el FQDN redactado

vagrant @ ansible-head : ~ $ sudo -u vagrant ansible-playbook -i inventario ubuntu-apache2.yaml

PLAY [servidor web] * * * * * * * * * * * * * * * * * * * *

REUNIENDO HECHOS * * * * * * * * * * * * * * * * * * * *
ok: [host1. **]

TAREA: [Actualizaciones caché de apt] * * * * * * * * * * * * * * * *
fallido: [host1. **] => {"fallido": verdadero}
msg: no se pudo bloquear apto para operación exclusiva

FATAL: todos los hosts ya han fallado - abortando

JUGAR CRÓNICA * * * * * * * * * * * * * * * * * * * * * *
para volver a intentarlo, use: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 cambiado = 0 inaccesible = 0 fallido = 1

Ejecutar manualmente ansible obtiene el mismo error:

vagrant @ ansible-head: ~ $ sudo -u vagabundo ansible webserver -i inventario -m apt -a "update_cache = yes
"
host1. *** | FALLIDO >> {
"fallido": cierto,
"msg": "No se pudo bloquear apto para operación exclusiva"
}

@Ravenwater Eso parece ser un problema diferente, ¿podría abrir un nuevo problema de github para él? Es posible que también desee preguntar en la lista de correo para ver si otros se han encontrado con eso. ¡Gracias!

Tengo un problema similar con ansible 1.3.4.

Si uso:

apt: update_cache=yes:

Recibo el mismo mensaje de error:

msg: Failed to lock apt for exclusive operation

También al instalar un paquete con la opción update_cache:

apt: pkg=openjdk-6-jre-headless state=installed update_cache=yes cache_valid_time=604800

Se muestra un error similar:

msg: 'apt-get install 'openjdk-6-jre-headless' ' failed: E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

El error aparece de forma intermitente. De hecho, usando un conjunto de 50 máquinas virtuales EC2 con ubuntu 12.04 (todas usando la misma imagen base, ami-e50e888c). El error aparece de 5 a 20 según la prueba.

"sudo: true" se especifica en el libro de jugadas.

Esto suele ser exactamente como dice el mensaje, o no tiene
permisos para bloquear la base de datos dpkg u otra persona (o usted en otro proceso)
lo ha bloqueado (esto me pasa si controlo + C en el medio e intento
otra vez).

Si. Pero usándolo con 50 VM con el mismo SO con la misma configuración en algunos de ellos funciona y en otros falla. Además, si vuelvo a intentar el libro de jugadas 3 o 4 veces, finalmente funciona en todos los nodos.

@micafer ¿ es posible que otros usuarios / procesos estén llamando a apt al mismo tiempo en esas máquinas?

Lo estoy probando con un conjunto de 50 máquinas virtuales creadas especialmente para estas pruebas, y soy el único usuario en todas.
No sé si ubuntu tiene algún proceso interno (cron o similar) que usa los comandos apt.

ubuntu tiene actualizaciones de caché cronned diariamente, normalmente escalonadas para no
crear un problema de 'manada atronadora', si ha instalado y desatendido
habilitado, también obtendrá actualizaciones de seguridad automáticas que también bloquearán
esta.

Votaría a favor de reabrir este problema ya que en la vida real existe una gran posibilidad de que esto suceda y ansible debería proporcionar una solución para ello, una solución que no involucre a un humano que lo intente hasta que funcione.

Ubuntu 16.04

Para el usuario de Ubuntu 16.04 (aunque creo que también podría suceder en la versión 15.04), Ubuntu se envía con unattended-upgrade habilitado _de forma predeterminada_. Comprueba regularmente las actualizaciones de seguridad (generalmente a diario), como lo menciona @bcoca. Entonces, la solución es agregar una tarea antes de tocar APT:

- name: kill automatic updating script, if any
  command: pkill --full /usr/bin/unattended-upgrade
  become: true
  register: kill_result
  failed_when: kill_result.rc > 1 # rc == 1 if the script is inactive
  changed_when: kill_result.rc == 0

Debería ser seguro, ya que el sistema volverá a ejecutar el script más tarde.

Solo un comentario de que no funcionó para mí, el bloqueo permaneció en su lugar incluso con el comando anterior. Pero como estoy implementando en EC2, simplemente actualicé mi imagen base eliminando manualmente unattended-upgrades .