Ansible: apt: update_cache = yes falhando no ansible 1.3 (?)

Como você está invocando o ansible-playbook, com -K? Houve uma mudança em 1.3 que sudo deve ser especificado explicitamente, pois o sinalizador -K não fará com que as tarefas usem sudo implicitamente.

Sim, eu estava usando -K e usando sudo explicitamente na maioria dos lugares, mas não em
neste caso específico. Então, provavelmente esse é o isse.

Muito respeitosamente,

Dan CaJacob

Na terça, 17 de setembro de 2013 às 16:23, James Cammarata
notificaçõ[email protected] :

Como você está invocando o ansible-playbook, com -K? Houve uma mudança em 1.3
que sudo deve ser explicitamente especificado, pois a sinalização -K não fará tarefas
use sudo implicitamente.

-
Responda diretamente a este e-mail ou visualize-o em Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

Ok, vou deixar você confirmar isso e se sim, vamos fechar isso. Obrigado!

Vai fazer. Obrigado!

Muito respeitosamente,

Dan CaJacob

Na terça, 17 de setembro de 2013 às 16:27, James Cammarata
notificaçõ[email protected] :

Ok, vou deixar você confirmar isso e se sim, vamos fechar isso. Obrigado!

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

Qualquer acompanhamento sobre isso?

Prosseguindo e encerrando, se você ainda tiver problemas, informe-nos. Obrigado!

Também estou enfrentando esse problema. Executando 1.3.2, mas não tenho referências de versões antigas para seguir.

Ao usar -KI, ocorre outra falha: conexão ssh fechada, aguardando o prompt de senha do sudo.

No final, preciso executar isso não no modo interativo, então o -K não pode ser a resposta final.

Mais detalhes: executando manualmente: host1. *** é o FQDN editado

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

PLAY [webserver] * * * * * * * * * * * * * * * * * * * * *

RECOLHENDO FATOS * * * * * * * * * * * * * * * * * * * *
ok: [host1. **]

TAREFA: [Atualiza o cache do apt] * * * * * * * * * * * * * * * *
falhou: [host1. **] => {"falhou": verdadeiro}
msg: Falha ao bloquear apt para operação exclusiva

FATAL: todos os hosts já falharam - abortando

JOGAR RECAP * * * * * * * * * * * * * * * * * * * * * *
para tentar novamente, use: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 alterado = 0 inacessível = 0 falhou = 1

Executar manualmente ansible get dá o mesmo erro:

vagrant @ ansible-head: ~ $ sudo -u servidor web vagrant ansible -i inventário -m apt -a "update_cache = yes
"
host1. *** | FALHOU >> {
"falhou": verdadeiro,
"msg": "Falha ao bloquear apt para operação exclusiva"
}

@Ravenwater Esse parece ser um problema diferente, você poderia abrir um novo problema no github para ele? Você também pode perguntar na lista de discussão para ver se outras pessoas encontraram isso. Obrigado!

Estou tendo um problema semelhante com o ansible 1.3.4.

Se eu usar:

apt: update_cache=yes:

Eu recebo a mesma mensagem de erro:

msg: Failed to lock apt for exclusive operation

Além disso, ao instalar um pacote com a opção update_cache:

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

Um erro semelhante é mostrado:

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?

O erro aparece intermitentemente. Na verdade, usando um conjunto de 50 máquinas virtuais EC2 com o ubuntu 12.04 (todas usando a mesma imagem de base, ami-e50e888c). O erro aparece em 5 a 20 dependendo do teste.

"sudo: true" é especificado no manual.

Normalmente é exatamente como a mensagem diz, ou você não tem
permissões para bloquear o dpkg db ou outra pessoa (ou você em outro processo)
travou (isso acontece comigo se eu controlar + C no meio e tentar
novamente).

Sim. Mas usá-lo com 50 VM com o mesmo SO com a mesma configuração em alguns funciona e em outros falha. Além disso, se eu repetir o manual 3 ou 4 vezes, ele funcionará em todos os nós.

@micafer é possível que outros usuários / processos estejam chamando o apt ao mesmo tempo nessas máquinas?

Estou testando com um conjunto de 50 VMs especialmente criadas para esses testes, e sou o único usuário em todas elas.
Não sei se o ubuntu tem algum processo interno (cron ou similar) que usa os comandos apt.

ubuntu tem atualizações de cache cronned diariamente, normalmente escalonadas para não
criar o problema de 'manada trovejante', se você tiver instalado e
ativado, você também obterá atualizações de segurança automáticas que também bloquearão
esta.

Eu votaria pela reabertura desse assunto, pois na vida real há uma chance séria de isso acontecer e o ansible deve fornecer uma solução para isso, uma solução que não envolva um humano que tente até que funcione.

Ubuntu 16.04

Para o usuário do Ubuntu 16.04 (embora eu ache que pode acontecer no 15.04 também), o Ubuntu vem com unattended-upgrade habilitado _por padrão_. Ele verifica regularmente se há atualizações de segurança (geralmente diariamente), conforme mencionado por @bcoca. Portanto, a solução é adicionar uma tarefa antes de tocar no 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

Deve ser seguro, pois o script será iniciado novamente mais tarde pelo sistema.

Apenas um comentário de que não funcionou para mim, a fechadura permaneceu no lugar mesmo com o comando acima. Mas enquanto estou implantando no EC2, simplesmente atualizei minha imagem base removendo manualmente unattended-upgrades .