Ansible: apt: update_cache = yes не работает в ansible 1.3 (?)

Как вы вызываете ansible-playbook с -K? В 1.3 было изменение, согласно которому sudo необходимо указывать явно, поскольку флаг -K не заставляет задачи использовать sudo неявно.

Да, я использовал -K и явно использовал sudo в большинстве мест, но не в
это конкретный случай. Так что, наверное, иссе.

Очень уважительно,

Дэн Кэджэйкоб

Во вторник, 17 сентября 2013 г., 16:23, Джеймс Каммарата
[email protected] написал :

Как вы вызываете ansible-playbook с -K? Произошло изменение в 1.3
это sudo должно быть явно указано, поскольку флаг -K не будет выполнять задачи
неявно используйте sudo.

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

Хорошо, я позволю вам подтвердить это, и если да, мы закроем это. Благодаря!

Сделаю. Благодаря!

Очень уважительно,

Дэн Кэджэйкоб

Во вторник, 17 сентября 2013 г., 16:27, Джеймс Каммарата
[email protected] написал :

Хорошо, я позволю вам подтвердить это, и если да, мы закроем это. Благодаря!

-
Ответьте на это письмо напрямую или просмотрите его на Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

Какие-нибудь дальнейшие действия по этому поводу?

Пойдем дальше и закроем это, если у вас все еще есть проблема, дайте нам знать. Благодаря!

Я тоже сталкиваюсь с этой проблемой. Работает 1.3.2, но у меня нет ссылок на старые версии.

При использовании -K я получаю еще один сбой: соединение ssh закрыто в ожидании запроса пароля sudo.

В конце концов, мне нужно запустить это не в интерактивном режиме, поэтому -K не может быть окончательным ответом.

Подробнее: запуск вручную: host1. *** - это отредактированное полное доменное имя

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

ИГРАТЬ [веб-сервер] * * * * * * * * * * * * * * * * * * * *

СОБИРАЕМ ФАКТЫ * * * * * * * * * * * * * * * * * * * *
ок: [host1. **]

ЗАДАЧА: [Обновляет кеш apt] * * * * * * * * * * * * * * * *
не удалось: [host1. **] => {"failed": true}
msg: Не удалось заблокировать подходящую для монопольной операции

FATAL: все хосты уже вышли из строя - прерывание

ИГРАТЬ резюмировать * * * * * * * * * * * * * * * * * * * * * *
чтобы повторить попытку, используйте: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 изменено = 0 недоступно = 0 не удалось = 1

При ручном запуске ansible возникает та же ошибка:

vagrant @ ansible-head: ~ $ sudo -u vagrant ansible webserver -i inventory -m apt -a "update_cache = yes
"
host1. *** | ВЫПОЛНЕНО >> {
"не удалось": правда,
«msg»: «Не удалось заблокировать подходящую для монопольной операции»
}

@Ravenwater Это другая проблема, не могли бы вы открыть для нее новую проблему с github? Вы также можете спросить в списке рассылки, не сталкивались ли другие с этим. Благодаря!

У меня аналогичная проблема с ansible 1.3.4.

Если я использую:

apt: update_cache=yes:

Я получаю такое же сообщение об ошибке:

msg: Failed to lock apt for exclusive operation

Также при установке пакета с опцией update_cache:

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

Показана аналогичная ошибка:

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?

Ошибка появляется периодически. Фактически используется набор из 50 виртуальных машин EC2 с ubuntu 12.04 (все используют один и тот же базовый образ ami-e50e888c). Ошибка появляется от 5 до 20 в зависимости от теста.

"sudo: true" указано в playbook.

Обычно это именно то, что написано в сообщении, либо у вас нет
разрешения на блокировку dpkg db или кого-то еще (или вас в другом процессе)
заблокировал его (это происходит со мной, если я контролирую + C в середине и пытаюсь
очередной раз).

Да. Но при использовании его с 50 ВМ с той же ОС с той же конфигурацией в некоторых из них он работает, а в других - нет. Более того, если я повторю playbook 3 или 4 раза, наконец, он работает во всех узлах.

@micafer, возможно ли, что другие пользователи / процессы одновременно вызывают apt на этих машинах?

Я тестирую его с набором из 50 виртуальных машин, специально созданных для этих тестов, и я единственный пользователь во всех из них.
Я не знаю, есть ли в ubuntu какой-либо внутренний процесс (cron или аналогичный), который использует команды apt.

ubuntu ежедневно обновляет кеш-память, обычно ступенчато, чтобы не
создать проблему «громового стада», если у вас установлена ​​автоматическая установка и
включен, вы также получите автоматические обновления безопасности, которые также заблокируют
это.

Я бы проголосовал за повторное открытие этого вопроса, поскольку в реальной жизни есть серьезный шанс, что это произойдет, и ansible должен предоставить решение для этого, решение, которое не требует участия человека, который пробует его, пока он не сработает.

Ubuntu 16.04

Для пользователя Ubuntu 16.04 (хотя я думаю, что это может произойти и в 15.04) Ubuntu поставляется с включенным unattended-upgrade _по умолчанию_. Он регулярно проверяет наличие обновлений безопасности (обычно ежедневно), как упоминает @bcoca. Итак, решение состоит в том, чтобы добавить задачу перед тем, как коснуться 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

Это должно быть безопасно, так как скрипт будет снова запущен системой позже.

Просто комментарий, что у меня это не сработало, блокировка оставалась на месте даже с приведенной выше командой. Но при развертывании на EC2 я просто обновил базовый образ, вручную удалив unattended-upgrades .