Fabric: تعطلت إعادة التشغيل على مضيفي Ubuntu 16.04

إنه نفس الشيء تمامًا مع run ('reboot')

كونه هو نفسه مع دليل run غير مفاجئ - من الواضح أن شيئًا ما تغير فيما يتعلق بمعالجة Ubuntu لإعادة التشغيل ، واتصالات SSH ، وما إلى ذلك.

لم يتبادر إلى الذهن شيء واضح ، لكن reboot() (Fab's ، وليس Linux) أساسي جدًا - فهو ببساطة يستدعي sudo('reboot') ، ويقوم بتعديل إعدادات إعادة الاتصال العامة لـ Fabric مؤقتًا حتى يتمكن من التعامل مع إعادة الاتصال بعد تسلسل إعادة تشغيل غير بديهي (مقابل الافتراضي ، والذي من شأنه أن يستسلم بسرعة كبيرة).

راجع https://github.com/fabric/fabric/blob/c0224a52df59821f21a8c0bd47ce15e42c2046a4/fabric/operations.py#L1244 - قد ترغب في محاولة تعديل ذلك.

حاول أيضًا تمكين تسجيل Paramiko (انظر أسفل صفحة تحري الخلل وإصلاحه - http://www.fabfile.org/troubleshooting.html) لأنه قد ينتج عنه دليل.

في الواقع ، عند التفكير الثاني ، يبدو أن Ubuntu reboot بطريقة أو بأخرى لا يخرج أو يرسل رمز خروج إلى معالجات تنفيذ Fabric ( run / sudo ) ، حيث لاحظت أن sudo هو ما يصاب بالجنون عندما تهرس Enter بعد الانتظار.

إذا نظرت إلى الكود reboot() ، فستتوقع أن يتم إنهاء المكالمة sudo('reboot') في النهاية ، بحيث يمكن أ) الانتظار قليلاً و B) بدء إعادة الاتصال.

حقيقة أن التنفيذ ، في نهاية Fabric ، معلق في sudo يعني أن شيئًا ما ينتهك هذا التوقع عن بعد. نوع غريب. _ربما _ خطأ في Fabric نفسه ، لكنه يبدو أشبه بسلوك سيء على الطرف البعيد. (ملاحظة: ما هو إصدار القماش الذي تشاهده؟)

فكرة مرتجعة - ربما يمكننا تعيين timeout= على sudo ، ثم except TimeoutException: pass حوله. سيضمن هذا أنه حتى في هذا الموقف (الغريب) ، فإننا نفترض محاولة إعادة الاتصال.

سيكون الجانب السلبي فقط هو الحالة التي يكون فيها reboot معلقًا بالفعل ولا يتم إعادة تشغيل النظام حقًا ، ولكن ليس الأمر كما لو أننا نجعل الأشياء _ أسوأ _ لهذه الحالة من خلال التغيير أعلاه - سيحدث التعليق اللانهائي في حلقة الاتصال بدلاً من داخل sudo .

سلوك آخر غريب حقًا متغير في Ubuntu 16.04 هو ما يلي. عندما أقوم بتشغيل poweroff في جلسة ssh ، يتوقف الجهاز عن التشغيل ، لكن جلسات SSH تتوقف! لا توجد طريقة لاستخدام Ctrl + C أو Ctrl + D أو أي شيء. كل ما يمكنني فعله هو انتظار _lot_ ثم إحباط ssh باستخدام:
packet_write_wait: Connection to 192.168.56.11: Broken pipe

أنا حقًا لست في الجيوب العميقة للتعامل مع اتصال SSH ، ولكن قد تكون هذه هي نفس المشكلة تمامًا كما هو الحال مع إعادة التشغيل.

لقد واجهت للتو عملية إعادة تشغيل مكسورة (Ubuntu 16.04 محدث حديثًا على AWS ، Fabric == 1.12.0) ولكن بطريقة مختلفة. بالنسبة لي مجرد رميات:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "reboot"

تشغيل sudo reboot في الوحدة الطرفية يدويًا (عمليات إعادة تشغيل المضيف).

قد يكون من الجدير بالذكر:

$ readlink /sbin/reboot 
/bin/systemctl
$ readlink /sbin/shutdown
/bin/systemctl

وشيء غريب آخر. لقد قمت بتغيير رمز إعادة التشغيل لاستخدام aws-cli وبعد الاستدعاء (الذي يستغرق حوالي 1 ثانية ، يبدو أنه غير متزامن) قمت بتشغيل sudo('add-apt-repository --yes ppa:nginx/stable') . لقد نجحت دائمًا ، ولكن الآن بعد إعادة التشغيل عادت -1 أيضًا:

sudo: add-apt-repository --yes ppa:nginx/stable

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: add-apt-repository --yes ppa:nginx/stable
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "add-apt-repository --yes ppa:nginx/stable"

ثم حاولت صنع قماش لإعادة الاتصال عن طريق إضافة fabric.network.disconnect_all() . نتج عن ذلك طلب كلمة مرور (لماذا ؟؟):

[...] sudo: add-apt-repository --yes ppa:nginx/stable
[...] Login password for 'ubuntu': 

وقد بدأ العمل فقط بعد أن أضفت على سبيل المثال time.sleep(60 * 3) بعد إعادة التشغيل. من الواضح أنها أداة مساعدة سيئة ، والآن أشعر بالحيرة بشأن كيفية التعامل مع مشكلة كلمة المرور بشكل صحيح. يبدو أنه مرتبط بهذه المشكلة.

يبدو أن المشكلة هي أن "إعادة التشغيل" تكون في بعض الأحيان "سريعة جدًا" في بعض الأحيان ، قبل أن تعود حالة الأمر عبر اتصال ssh.

(نصيحة: إذا كنت في اتصال ssh متجمد نتيجة لذلك: اكتب \n~. aka enter، tilde، period. هذا هو حرف الهروب الافتراضي ssh ، ثم أمر قطع الاتصال لـ ssh. إذا حاولت فقط ctrl- c أو ctrl-d ، يحاول ssh تمرير ذلك إلى العملية التي تعمل على الجانب الآخر.)

أحد الحلول هو استخدام shutdown -r +1 ، والذي سيقوم بجدولة إعادة التشغيل للدقيقة التالية ، ثم الانتظار لمدة دقيقة حتى يبدأ ، ثم البدء في محاولة إعادة الاتصال. من المسلم به أن الانتظار لمدة دقيقة ليس بالأمر الرائع.

شيء مخادع يجب تجربته: يجب أن يكون shutdown -r +0 معادلاً لـ reboot ، لكن في اختباراتي المحدودة لـ Ubuntu-16.04 التي تعمل في VirtualBox ، تميل إلى إعطاء جزء من الثانية لفترة أطول ، مع إظهار التالي موجه shell قبل فصل جلسة ssh اليدوية.

ربما هذا هو نسخة مزدوجة من # 1444

إذا تم تبديل البرنامج الخفي لـ init لإعادة التشغيل فإن إعادة التشغيل تعمل كما هو متوقع. يبدو أن systemd يقتل sshd على الفور.

كان هناك خطأ في حزمة systemd الخاصة بـ Debian / Ubuntu أدى ، عند إيقاف التشغيل ، إلى إنهاء خدمة الشبكة قبل خدمة SSH ، لذا توقف كل شيء.
تم إصلاحه في أحدث إصدار من النقاط. لا تعرف حالة حزمة Ubuntu.

https://bugs.debian.org/cgi-bin/bugreport.cgi؟bug=751636

تم الإبلاغ عن الخطأ في Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002

لدي أيضًا مشكلات تتعلق باستخدام إعادة التشغيل () في بعض البرامج النصية الخاصة بي. اكتشفت أنه عند الاتصال بكلمة مرور ، كانت عملية إعادة التشغيل تعمل بشكل صحيح ، ولكن عند استخدام مصادقة ملف المفاتيح ، تم قطع الاتصال (تمت إعادة التشغيل).

تم وضع علامة على خطأ ubuntu https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002 على أنه تم إصلاحه في 16.10 ، ولكن ليس بعد في 16.04 ، ومن غير الواضح متى سيكون كذلك.

السلوك الحالي بالنسبة لي هو أن paramiko / fabric يكتشف على الفور أن اتصال ssh قد تم إغلاقه ، ولكن قبل أن يرى paramiko / fabric أن أمر إعادة التشغيل قد اكتمل. على الأقل لا يتم تعليقه إلى أجل غير مسمى كما في التقرير الأصلي.

Fatal error: sudo() received nonzero return code -1 while executing!
...
Aborting.

لقد أجرى reboot() ذلك باستمرار من أجلي في عدد قليل من الاختبارات مقابل AWS EC2 و Virtualbox VM محلي. (لقد استخدمت دائمًا مصادقة ملف المفتاح.)

لقد وجدت حلاً قصيرًا وأنيقًا ، كما اقترحت دون الكثير من التفاصيل أعلاه:

reboot(command="shutdown -r +0")

لقد نجح ذلك كما هو متوقع بالنسبة لي (في عدد قليل من الاختبارات التي أجريتها ضد AWS EC2 و Virtualbox VM المحلي ، وكلها تعمل بنظام ubuntu 16.04 المحدث) لاحظ أن "shutdown -r now" تصرف مثل "إعادة التشغيل" ولا يبدو أنه يعمل.

لقد ألقيت نظرة سريعة على صفحات freebsd و openbsd man ، ويبدو أن لديهم أمر إيقاف التشغيل يدعم هذه المعلمات. أظن أن الأمر "shutdown -r +0" سيعمل إلى حد كبير مع أي نظام يونكس يعمل على "إعادة التشغيل". لذلك يمكن النظر في تغيير الأمر الافتراضي ، أو تحديث الوثائق. (لكنني سأكون مهتمًا برؤية تقرير عن اختبار على نظام BSD أولاً.)

لا يكفينا shutdown -r +0 . نظرًا لأن إعادة التشغيل لا تقبل المهلة اليدوية ، فقد جربت شيئًا مثل:

try:
    sudo("shutdown -r +0", timeout=300)
except NetworkError:
    pass
# in case the sudo times out during reboot
sleep(15)

على الرغم من كل هذه التلويح باليد ، فإن الأمر التالي معلق إلى أجل غير مسمى. هل من الممكن أن يكون تجمع الاتصال متمسكًا (ويستخدم) الاتصال الميت؟ إذا كان الأمر كذلك، فإن هناك حلا؟ هل يمكنني تقليل مهلة مستوى الاتصال مؤقتًا؟

في الواقع ، تحتاج إلى استبدال الاتصال الحالي ، بالطريقة التي يعمل بها reboot() :

https://github.com/fabric/fabric/blob/1.13.2/fabric/operations.py#L1289 -L1294

نعتذر لإحياء مشكلة قديمة ، يمكنني أيضًا أن أؤكد أن هذه المشكلة تحدث عند محاولة إعادة تشغيل حاوية LXC. اقتراحploxiln باستخدام command="shutdown -r +0" لم ينجح معنا.

تأكيد هذا الخطأ في تثبيت جديد لـ FreeBSD 11.1 مع تثبيت bash:

reboot(wait=1) في:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /usr/local/bin/bash -l -c "reboot"

Aborting.
Traceback (most recent call last):
…
    raise env.abort_exception(msg)
hosts.FabricException: sudo() received nonzero return code -1 while executing!

انتهى بي الأمر بالحاجة إلى هذا للحصول على الأشياء بعد إعادة كتابة @ ambsw-technology و ploxiln التعليقات. أنا أعمل ضد خادم ubuntu 16.04 LTS (من عميل windows).

sudo('shutdown -r +0')
time.sleep(30)
fabric.state.connections.connect(env.host_string)

لمعلوماتك ، ما زلت أرى هذا مقابل خوادم 18.04.2 LTS.

أي إصلاح لهذا؟ أيضًا الحصول على مشكلة مع 16.04