Ansible: apt: update_cache = yes échec dans ansible 1.3 (?)

Comment invoquez-vous ansible-playbook, avec -K? Il y a eu un changement dans la 1.3 selon lequel sudo doit être explicitement spécifié car l'indicateur -K ne fera pas que les tâches utilisent sudo implicitement.

Ouais, j'utilisais -K et j'utilisais explicitement sudo dans la plupart des endroits, mais pas dans
ce cas précis. Donc, c'est probablement l'isse.

Très respectueusement,

Dan CaJacob

Le mar 17 septembre 2013 à 16:23, James Cammarata
[email protected] a écrit :

Comment invoquez-vous ansible-playbook, avec -K? Il y a eu un changement dans 1.3
que sudo doit être explicitement spécifié car l'indicateur -K ne fera pas de tâches
utilisez sudo implicitement.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

Ok, je vous laisse le confirmer et si c'est le cas, nous clôturerons cela. Merci!

Ça ira. Merci!

Très respectueusement,

Dan CaJacob

Le mar 17 septembre 2013 à 16:27, James Cammarata
[email protected] a écrit :

Ok, je vous laisse le confirmer et si c'est le cas, nous clôturerons cela. Merci!

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

Un suivi à ce sujet?

Allez-y et fermez ceci, si vous rencontrez toujours un problème, faites-nous savoir. Merci!

Je rencontre également ce problème. Exécution de 1.3.2 mais je n'ai pas d'anciennes références de version.

Lorsque vous utilisez -K, j'obtiens un autre échec: la connexion ssh est fermée en attente de l'invite du mot de passe sudo.

En fin de compte, je dois l'exécuter pas en mode interactif, donc le -K ne peut pas être la réponse finale.

Plus de détails: exécution manuelle: host1. *** est le nom de domaine complet expurgé

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

PLAY [serveur Web] * * * * * * * * * * * * * * * * * * * *

RASSEMBLEMENT DES FAITS * * * * * * * * * * * * * * * * * * * *
ok: [hôte1. **]

TÂCHE: [Met à jour le cache apt] * * * * * * * * * * * * * * * *
failed: [host1. **] => {"failed": true}
msg: échec du verrouillage d'apt pour une opération exclusive

FATAL: tous les hôtes ont déjà échoué - abandon

RECAP LECTURE * * * * * * * * * * * * * * * * * * * * * *
pour réessayer, utilisez: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 changé = 0 inaccessible = 0 échoué = 1

L'exécution manuelle d'ansible obtient la même erreur:

vagrant @ ansible-head: ~ $ sudo -u vagrant ansible webserver -i inventaire -m apt -a "update_cache = yes
"
hôte1. *** | ÉCHEC >> {
"échoué": vrai,
"msg": "Impossible de verrouiller apt pour une opération exclusive"
}

@Ravenwater Cela semble être un problème différent, pourriez-vous ouvrir un nouveau problème github pour cela? Vous voudrez peut-être également demander sur la liste de diffusion pour voir si d'autres ont rencontré cela. Merci!

J'ai un problème similaire avec ansible 1.3.4.

Si j'utilise:

apt: update_cache=yes:

J'obtiens le même message d'erreur:

msg: Failed to lock apt for exclusive operation

Aussi lors de l'installation d'un package avec l'option update_cache:

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

Une erreur similaire est affichée:

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?

L'erreur apparaît par intermittence. En fait, en utilisant un ensemble de 50 machines virtuelles EC2 avec ubuntu 12.04 (utilisant toutes la même image de base, ami-e50e888c). L'erreur apparaît dans 5 à 20 selon le test.

"sudo: true" est spécifié dans le playbook.

C'est normalement exactement ce que dit le message, soit vous n'avez pas
autorisations pour verrouiller la base de données dpkg ou quelqu'un d'autre (ou vous dans un autre processus)
l'a verrouillé (cela m'arrive si je contrôle + C au milieu et que j'essaye
encore).

Oui. Mais en l'utilisant avec 50 VM avec le même OS avec la même configuration dans certains d'entre eux, cela fonctionne et dans d'autres, cela échoue. De plus, si je réessaye le playbook 3 ou 4 fois finalement cela fonctionne dans tous les nœuds.

@micafer est-il possible que d'autres utilisateurs / processus appellent apt en même temps sur ces machines?

Je le teste avec un ensemble de 50 machines virtuelles spécialement créées pour ces tests, et je suis le seul utilisateur de tous.
Je ne sais pas si ubuntu a un processus interne (cron ou similaire) qui utilise les commandes apt.

ubuntu a créé des mises à jour de cache quotidiennement, normalement échelonnées pour ne pas
créer un problème de `` troupeau tonitruant '', si vous avez installé et
activé, vous obtiendrez également des mises à jour de sécurité automatiques qui verrouillent également
ce.

Je voterais pour la réouverture de cette question car dans la vraie vie, il y a de sérieuses chances que cela se produise et ansible devrait y apporter une solution, une solution qui n'implique pas un humain qui l'essaie jusqu'à ce que cela fonctionne.

Ubuntu 16.04

Pour les utilisateurs d'Ubuntu 16.04 (bien que je pense que cela pourrait également arriver dans 15.04), Ubuntu est livré avec unattended-upgrade activé _par défaut_. Il vérifie régulièrement les mises à jour de sécurité (généralement quotidiennement), comme mentionné par @bcoca. La solution est donc d'ajouter une tâche avant de toucher 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

Cela devrait être sûr, car le script sera relancé plus tard par le système.

Juste un commentaire que cela n'a pas fonctionné pour moi, le verrou est resté en place même avec la commande ci-dessus. Mais comme je déploie sur EC2, j'ai simplement mis à jour mon image de base en supprimant manuellement unattended-upgrades .