Ansible: apt: update_cache = yes gagal pada kemungkinan 1.3 (?)

Bagaimana Anda menggunakan ansible-playbook, dengan -K? Ada perubahan di 1.3 bahwa sudo harus ditentukan secara eksplisit karena tanda -K tidak akan membuat tugas menggunakan sudo secara implisit.

Ya, saya menggunakan -K dan menggunakan sudo secara eksplisit di banyak tempat, tetapi tidak di
kasus khusus ini. Jadi, itu mungkin isse.

Dengan sangat hormat,

Dan CaJacob

Pada Sel, 17 Sep 2013 jam 16.23, James Cammarata
[email protected] :

Bagaimana Anda menggunakan ansible-playbook, dengan -K? Ada perubahan di 1.3
sudo itu harus ditentukan secara eksplisit karena tanda -K tidak akan membuat tugas
gunakan sudo secara implisit.

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

Oke, saya akan membiarkan Anda mengonfirmasi itu dan jika demikian kami akan menutup ini. Terima kasih!

Akan melakukan. Terima kasih!

Dengan sangat hormat,

Dan CaJacob

Pada Sel, 17 Sep 2013 jam 16.27, James Cammarata
[email protected] :

Oke, saya akan membiarkan Anda mengonfirmasi itu dan jika demikian kami akan menutup ini. Terima kasih!

-
Balas email ini secara langsung atau lihat di Gi tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

Ada tindak lanjut tentang ini?

Akan melanjutkan dan menutup ini, jika Anda masih mengalami masalah, beri tahu kami. Terima kasih!

Saya mengalami masalah ini juga. Menjalankan 1.3.2 tetapi saya tidak memiliki referensi versi lama untuk digunakan.

Saat menggunakan -KI dapatkan kegagalan lain: koneksi ssh ditutup menunggu prompt kata sandi sudo.

Pada akhirnya saya perlu menjalankan ini bukan dalam mode interaktif, jadi -K tidak bisa menjadi jawaban akhir.

Lebih detail: berjalan secara manual: host1. *** adalah FQDN yang telah disunting

gelandangan @ ansible-head : ~ $ sudo -u gelandangan ansible-playbook -i inventaris ubuntu-apache2.yaml

MAINKAN [server web] * * * * * * * * * * * * * * * * * * * *

MENGUMPULKAN FAKTA * * * * * * * * * * * * * * * * * * * *
oke: [host1. **]

TUGAS: [Memperbarui apt cache] * * * * * * * * * * * * * * * *
gagal: [host1. **] => {"gagal": true}
msg: Gagal mengunci apt untuk operasi eksklusif

FATAL: semua host telah gagal - membatalkan

MAINKAN REKAP * * * * * * * * * * * * * * * * * * * * * *
untuk mencoba lagi, gunakan: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

host1. ***: ok = 1 diubah = 0 tidak terjangkau = 0 gagal = 1

Menjalankan secara manual kemungkinan mendapatkan kesalahan yang sama:

gelandangan @ ansible-head: ~ $ sudo -u gelandangan server web yang mungkin -i inventaris -m apt -a "update_cache = yes
"
host1. *** | GAGAL >> {
"gagal": benar,
"msg": "Gagal mengunci apt untuk operasi eksklusif"
}

@Ravenwater Itu tampaknya menjadi masalah yang berbeda, dapatkah Anda membuka masalah github baru untuk itu? Anda mungkin juga ingin bertanya di milis untuk mengetahui apakah orang lain mengalaminya. Terima kasih!

Saya mengalami masalah serupa dengan kemungkinan 1.3.4.

Jika saya menggunakan:

apt: update_cache=yes:

Saya mendapatkan pesan kesalahan yang sama:

msg: Failed to lock apt for exclusive operation

Juga saat menginstal paket dengan opsi update_cache:

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

Kesalahan serupa ditampilkan:

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?

Kesalahan muncul sesekali. Bahkan menggunakan satu set 50 mesin virtual EC2 dengan ubuntu 12.04 (semua menggunakan gambar dasar yang sama, ami-e50e888c). Kesalahan muncul dalam 5 hingga 20 tergantung pada tes.

"sudo: true" ditentukan di pedoman.

Ini biasanya persis seperti yang dikatakan pesan, Anda tidak punya
izin untuk mengunci dpkg db atau orang lain (atau Anda dalam proses lain)
telah menguncinya (ini terjadi pada saya jika saya mengontrol + C di tengah dan mencoba
lagi).

Iya. Tetapi menggunakannya dengan 50 VM dengan OS yang sama dengan konfigurasi yang sama di beberapa di antaranya berhasil dan di lainnya gagal. Terlebih lagi jika saya mencoba ulang playbook 3 atau 4 kali akhirnya berfungsi di semua node.

@ mikafer mungkinkah pengguna / proses lain memanggil tepat pada waktu yang sama di mesin tersebut?

Saya mengujinya dengan satu set 50 VM yang dibuat khusus untuk pengujian ini, dan saya satu-satunya pengguna di semuanya.
Saya tidak tahu apakah ubuntu memiliki beberapa proses internal (cron atau serupa) yang menggunakan perintah apt.

ubuntu memiliki pembaruan cache yang di-cache setiap hari, biasanya melangkah agar tidak
membuat masalah 'thundering herd', jika Anda menginstal tanpa pengawasan dan
diaktifkan, Anda juga akan mendapatkan pembaruan keamanan otomatis yang juga akan terkunci
ini.

Saya akan memilih untuk membuka kembali masalah ini karena dalam kehidupan nyata ada peluang serius untuk hal ini terjadi dan seseorang harus memberikan solusi untuk itu, solusi yang tidak melibatkan manusia yang mencobanya sampai berhasil.

Ubuntu 16.04

Untuk pengguna Ubuntu 16.04 (meskipun saya pikir itu mungkin terjadi pada 15.04 juga), Ubuntu dikirimkan dengan unattended-upgrade enabled _by default_. Ini secara teratur memeriksa pembaruan keamanan (biasanya setiap hari), seperti yang disebutkan oleh @bcoca. Jadi solusinya adalah menambahkan tugas sebelum menyentuh 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

Ini harus aman, karena skrip akan diluncurkan lagi nanti oleh sistem.

Hanya komentar yang tidak berhasil untuk saya, kuncinya tetap di tempatnya bahkan dengan perintah di atas. Tetapi saat saya menerapkan EC2, saya hanya memperbarui gambar dasar saya dengan menghapus secara manual unattended-upgrades .