Ansible: apt：update_cache = yes ansible 1.3で失敗します（？）

-Kを使用してansible-playbookをどのように呼び出していますか？ 1.3では、-Kフラグがタスクにsudoを暗黙的に使用させないため、sudoを明示的に指定する必要があるという変更がありました。

ええ、私はほとんどの場所で-Kとsudoを明示的に使用していましたが、
この特定のケース。 だから、それはおそらく問題です。

非常に礼儀正しく、

ダン・カヤコブ

2013年9月17日火曜日午後4時23分、James Cammarata
[email protected] ：

-Kを使用してansible-playbookをどのように呼び出していますか？ 1.3で変更がありました
-Kフラグはタスクを実行しないため、sudoを明示的に指定する必要があります
sudoを暗黙的に使用します。

—
このメールに直接返信するか、Gi tHubhttps：//github.com/ansible/ansible/issues/4140#issuecomment-24619163で表示してください
。

わかりました。確認させていただきます。確認した場合は終了します。 ありがとう！

しましょう。 ありがとう！

非常に礼儀正しく、

ダン・カヤコブ

2013年9月17日火曜日午後4時27分、James Cammarata
[email protected] ：

わかりました。確認させていただきます。確認した場合は終了します。 ありがとう！

—
このメールに直接返信するか、Gi tHubhttps：//github.com/ansible/ansible/issues/4140#issuecomment-24619465で表示してください
。

これに関するフォローアップはありますか？

それでも問題が解決しない場合は、先に進んでこれを閉じてください。 ありがとう！

私もこの問題に直面しています。 1.3.2を実行していますが、古いバージョンの参照がありません。

-KIを使用すると、別のエラーが発生します。ssh接続が閉じられ、sudoパスワードプロンプトを待機しています。

結局、これをインタラクティブモードではなく実行する必要があるので、-Kを最終的な答えにすることはできません。

詳細：手動で実行：host1。***は編集されたFQDNです

vagrant @ ansible-head ：〜$ sudo -u vagrant ansible-playbook -i Inventory ubuntu-apache2.yaml

PLAY [ウェブサーバー] * * * * * * * * * * * * * * * * * * * *

GATHERINGのFACTS * * * * * * * * * * * * * * * * * * * *
わかりました：[host1。**]

タスク：[aptキャッシュを更新] * * * * * * * * * * * * * * * *
失敗：[host1。**] => {"失敗"：true}
msg：排他的操作のためにaptをロックできませんでした

致命的：すべてのホストがすでに失敗しています-中止

PLAY RECAP * * * * * * * * * * * * * * * * * * * * * *
再試行するには、次を使用します：-limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1。***：ok = 1変更= 0到達不能= 0失敗= 1

ansible getを手動で実行すると、同じエラーが発生します。

vagrant @ ansible-head：〜$ sudo -u vagrant ansible webserver -i Inventory -m apt -a "update_cache = yes
「」
host1。*** | 失敗しました>> {
「失敗」：true、
"msg"： "排他的操作のためにaptをロックできませんでした"
}

@Ravenwaterそれは別の問題のようですが、新しいgithubの問題を開くことができますか？ また、メーリングリストで、他の人がそれに遭遇したかどうかを確認することもできます。 ありがとう！

ansible1.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?

エラーが断続的に表示されます。 実際、ubuntu 12.04で50台のEC2仮想マシンのセットを使用しています（すべて同じベースイメージ、ami-e50e888cを使用しています）。 テストに応じて、5〜20でエラーが発生します。

ハンドブックで「sudo：true」が指定されています。

これは通常、メッセージに記載されているとおりです。
dpkg dbまたは他の誰か（または他のプロセスのあなた）をロックする権限
それをロックしました（これは、途中で+ Cを制御して試してみると私に起こります
再び）。

はい。 ただし、同じOSで同じ構成の50台のVMで使用すると、機能するものと失敗するものがあります。 さらに、プレイブックを3〜4回再試行すると、最終的にすべてのノードで機能します。

@micaferは、他のユーザー/プロセスがそれらのマシンで同時にaptを呼び出している可能性がありますか？

このテスト用に特別に作成された50個のVMのセットを使用してテストしており、それらすべての中で私が唯一のユーザーです。
ubuntuにaptコマンドを使用する内部プロセス（cronなど）があるかどうかはわかりません。

ubuntuはキャッシュの更新を毎日cronし、通常はそうしないようにステップしています
無人でインストールした場合は、「雷鳴の群れ」の問題を作成し、
有効にすると、自動セキュリティ更新も取得され、ロックされます
この。

私はこの問題を再開することに投票します。実際にはこれが発生する重大な可能性があり、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手動で削除してベースイメージを更新しただけです。