Как отследить ход выполнения автоматических обновлений или облачного инициализации? - PullRequest
Новая
       112

Как отследить ход выполнения автоматических обновлений или облачного инициализации?

1 голос
/ 07 октября 2019

Я хочу использовать Packer (сборка образов) и Ansible (инициатор) для предоставления Ubuntu AMI.

"name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",

У меня возникли трудности, поскольку некоторые задачи пытаются установить пакеты с помощью apt, но блокировка удерживается другим процессом. У меня возникают трудности с определением того, какие процессы удерживают блокировку наиболее важно, каков прогресс с этим определенным процессом.

По умолчанию AMI, который устанавливает amazon, будет устанавливать обновления безопасности при запуске [0], поэтому я предполагаю,это оно. Как объясняют документы, это может быть связано с cloud-init? Я полагаю, что это также относится к автоматическим обновлениям, так как, как вы можете видеть в этой вставке [1], есть процесс автоматического отключения обновлений, который ожидает, пока какой-то другой процесс (apt?) Завершит установку обновлений перед выключением.

Если я использую sudo lslocks, я получаю 

    amazon-ebs:         "COMMAND           PID  TYPE SIZE MODE  M START END PATH",
    amazon-ebs:         "lvmetad           433 POSIX   4B WRITE 0     0   0 /run/lvmetad.pid",
    amazon-ebs:         "iscsid           1082 POSIX   5B WRITE 0     0   0 /run/iscsid.pid",
    amazon-ebs:         "lxcfs            1110 POSIX   5B WRITE 0     0   0 /run/lxcfs.pid",
    amazon-ebs:         "cron             1134 FLOCK   5B WRITE 0     0   0 /run/crond.pid",
    amazon-ebs:         "atd              1127 POSIX   5B WRITE 0     0   0 /run/atd.pid"

, что не говорит мне много обо всех файлах, которые являются интересными для блокировки.

Если я tail /var/log/cloud-init-output.log, я вижу, что облачный init работает.

Если я tail /var/log/dpkg.log, я вижу журналы с 13 сентября, которых нет сегодня.

Если я tail /var/log/apt/term.log, я вижу журналы с 13 сентября, которых нет сегодня.

Это 

>&1 sudo fuser '/var/lib/dpkg/lock-frontend' || echo aa ;
>&1 sudo fuser -vvv /var/lib/apt/lock || echo a ;
>&1 sudo lsof /var/lib/apt/lists/lock || echo b ;
>&1 sudo lsof /var/lib/dpkg/lock || echo c ;
>&1 sudo lsof /var/cache/apt/archives/lock || echo d ;

выводит 

aa
a
b
c
d

, поэтому я понимаю, что эти файлы блокировки не существуют. Я озадачен, потому что есть ошибка в файле блокировки: Failed to lock apt for exclusive operation.

Как мне найти файл блокировки? И самое главное, как я могу отслеживать ход процесса, удерживающего эту блокировку?

Спасибо!

[0: документы по обновлениям безопасности] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-linux-ami-basics.html

[1: ps paste] https://pastebin.ubuntu.com/p/JGNkfVFHGJ/

Ответы [ 2 ]

1 голос
/ 07 октября 2019

Начиная с cloud-init v.18.2 или новее, статус cloud-init --wait будет блокироваться до завершения работы cloud-init. Таким образом, скрипт легко может использовать скрипт перед выполнением остальной части его работы.

0 голосов
/ 16 октября 2019

Кажется, что использование Packer с Ansible делает вещи немного сложнее. По какой-то причине я установил в своих конфигурациях Packer, что EC2 будет задействован в качестве пользователя ubuntu, а Ansible будет использовать пользователя root. Это привело к тому, что Ansible НЕ пытался запустить «sudo», потому что считал, что он уже root. Таким образом, он не смог захватить блокировку для установки пакетов.

Однако это не ответит, как отслеживать процесс установки пакетов. Я думаю, что взгляд на облако-инициацию дал хорошее представление о том, что происходит. Cloud-init был сделан, работает. Журналы apt не показали прогресса, поэтому я считаю, что он ничего не устанавливал.

...