Ansible: apt: update_cache = نعم الفشل في الإصدار 1.3 (؟)

كيف تستحضر كتاب اللعب مع -K؟ كان هناك تغيير في 1.3 يجب تحديد sudo صراحةً لأن العلامة -K لن تجعل المهام تستخدم sudo ضمنيًا.

نعم ، كنت أستخدم -K وأستخدم sudo بشكل صريح في معظم الأماكن ، ولكن ليس في
هذه الحالة المحددة. لذلك ، ربما يكون هذا هو عيسى.

بكل احترام،

دان كاجاكوب

يوم الثلاثاء ، 17 سبتمبر 2013 الساعة 4:23 مساءً ، جيمس كاماراتا
إخطاراتgithub.com

كيف تستحضر كتاب اللعب مع -K؟ كان هناك تغيير في 1.3
يجب تحديد sudo صراحةً لأن العلامة -K لن تقوم بمهام
استخدم sudo ضمنيًا.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619163
.

حسنًا ، سأدعك تؤكد ذلك وإذا كان الأمر كذلك فسنغلق هذا. شكر!

سوف تفعل. شكر!

بكل احترام،

دان كاجاكوب

يوم الثلاثاء ، 17 سبتمبر 2013 الساعة 4:27 مساءً ، جيمس كاماراتا
إخطاراتgithub.com

حسنًا ، سأدعك تؤكد ذلك وإذا كان الأمر كذلك فسنغلق هذا. شكر!

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو tHubhttps: //github.com/ansible/ansible/issues/4140#issuecomment -24619465
.

أي متابعة لهذا؟

المضي قدمًا وإغلاق هذا ، إذا كنت لا تزال تواجه مشكلة ، فأخبرنا بذلك. شكر!

أنا أواجه هذه المشكلة أيضًا. يعمل 1.3.2 ولكن ليس لدي مراجع الإصدار القديم للذهاب بها.

عند استخدام -KI حدث فشل آخر: تم إغلاق اتصال ssh في انتظار مطالبة كلمة مرور sudo.

في النهاية ، أحتاج إلى تشغيل هذا ليس في الوضع التفاعلي ، لذلك لا يمكن أن يكون -K هو الإجابة النهائية.

مزيد من التفاصيل: التشغيل يدويًا: host1. *** هو FQDN المنقح

المتشرد @ ansible-head : ~ $ sudo -u المتشرد ansible-playbook -i المخزون ubuntu-apache2.yaml

PLAY [خادم] * * * * * * * * * * * * * * * * * * * *

جمع الحقائق * * * * * * * * * * * * * * * * * * * *
حسنًا: [host1. **]

TASK: [التحديثات مخبأ ملائمة] * * * * * * * * * * * * * * * *
فشل: [host1. **] => {"فشل": صحيح}
msg: فشل في قفل apt لعملية خاصة

فادح: فشل جميع المضيفين بالفعل - إحباط

PLAY RECAP * * * * * * * * * * * * * * * * * * * * * *
لإعادة المحاولة ، استخدم: --limit @ / home / vagrant / ubuntu-apache2.yaml.retry

المضيف 1. ***: طيب = 1 تغير = 0 لا يمكن الوصول إليه = فشل 0 = 1

يدويا تشغيل ansible تحصل على نفس الخطأ:

vagrant @ ansible-head: ~ $ sudo -u خادم الويب المتشرد غير المرئي -i المخزون -m apt -a "update_cache = نعم
"
host1. *** | فشل >> {
"فشل": صحيح ،
"msg": "فشل في قفل apt لعملية خاصة"
}

Ravenwater يبدو أن هذه مشكلة مختلفة ، هل يمكنك فتح مشكلة جيثب جديدة لها؟ قد ترغب أيضًا في أن تسأل على القائمة البريدية لمعرفة ما إذا كان الآخرون قد واجهوا ذلك. شكر!

أواجه مشكلة مماثلة مع 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" في دليل التشغيل.

هذا عادة ما يكون بالضبط كما تقول الرسالة ، إما أنك لا تملكه
أذونات لقفل dpkg db أو شخص آخر (أو أنت في عملية أخرى)
لقد أغلقته (يحدث هذا لي إذا كنت تتحكم في + C في المنتصف وحاولت
مرة أخرى).

نعم. لكن استخدامه مع 50 VM مع نفس نظام التشغيل بنفس التكوين في بعضها يعمل ويفشل في البعض الآخر. علاوة على ذلك ، إذا أعدت محاولة كتاب اللعب 3 × 4 مرات ، فإنه يعمل في النهاية في جميع العقد.

micafer هل من الممكن أن يقوم مستخدمون / عمليات أخرى باستدعاء apt في نفس الوقت على تلك الأجهزة؟

أنا أختبرها بمجموعة من 50 جهاز افتراضي تم إنشاؤها خصيصًا لهذه الاختبارات ، وأنا المستخدم الوحيد فيها جميعًا.
لا أعرف ما إذا كان لدى أوبونتو بعض العمليات الداخلية (كرون أو ما شابه ذلك) التي تستخدم أوامر apt.

قام أوبونتو بتجميع تحديثات ذاكرة التخزين المؤقت يوميًا ، وعادةً ما يتم تصعيدها حتى لا تفعل ذلك
إنشاء مشكلة "القطيع الرعد" ، إذا كان لديك تثبيت غير مراقب و
ممكّنًا ، ستحصل أيضًا على تحديثات أمان تلقائية سيتم قفلها أيضًا
هذه.

أود أن أصوت لإعادة فتح هذه القضية لأنه في الحياة الواقعية هناك فرصة جادة لحدوث ذلك ويجب أن يوفر المرن حلاً لها ، وهو حل لا يتضمنه إنسان يحاول ذلك حتى يعمل.

نظام التشغيل Ubuntu 16.04.0

بالنسبة لمستخدم 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 يدويًا.