Supervisor: إشارات إعادة التشغيل غير مدعومة

1000 مرة هذا

+1

أود حقًا أن أكون قادرًا على استخدام عمليات إعادة التشغيل الرائعة لـ uwsgi ، والكرفس ، وما إلى ذلك التي أديرها تحت إشراف.

+1 كبيرة.

لاحظ أيضًا أنه لا يمكنك استخدام الاختراق supervisorctl pid [processname] | awk | xargs kill -SIGNAL للمجموعات التي تنتج أكثر من عملية.

أنا أستخدم supervisorctl pid appname | xargs kill -s HUP لـ gunicorn ، لكن طريقة إعادة التحميل المناسبة ، بدلاً من الاعتماد على الاختراق ، ستكون موضع ترحيب كبير.

+1 آخر لهذا!

+1 آخر

سيكون هذا رائعًا ، حيث يمكنني إجراء عمليات النشر تحت gunicorn دون إيقاف موقعي.

لم يتم التعامل مع هذا بالفعل مع stopsignal ؟ أنا أستخدمه في gunicorn طوال الوقت.

mattrobenolt لا أعتقد ذلك ، منذ ذلك الحين تشغيل supervisorctl stop gunicorn لن يوقف فعليًا gunicorn. سيكون مجرد إعادة تحميله.

أوه ، لقد فهمت ما تقوله. لكن الجينكورن يدعم الإغلاق الرشيق بإشارة QUIT. لذلك أستخدم stopsignal=QUIT في ملف conf الخاص بي لإعادة التحميل دون قطع العملية.

Stopsignal لا يحل مشكلتنا. لا يزال المشرف يتوقع العملية
لإيقافه وسيقضي عليه في النهاية.

سيكون وجود خيار إعادة التشغيل أمرًا جيدًا ...

إذا كان هناك اهتمام من المشرف سأكتب تصحيحًا لهذا ...

بالتأكيد +1 على هذا!

+1

اي كلمة في هذا؟

سيكون إجراء 1+ مفيدًا جدًا ، وفي الحقيقة هذه هي الميزة الوحيدة المهمة التي أفتقدها من المشرف والتي تعتبر بخلاف ذلك قطعة رائعة من البرامج

+2

+1 أيضًا مني! (بدون هذه الميزة لا يمكنني مشاهدة nginx مع المشرف ، وأود أن أفعل ذلك ، لأن المشرف جيد جدًا!)

أي شخص من فريق المشرف يقرأ هذا؟ ما هي حالة طلب الميزة هذا؟

+1

+1

+1

: +1:

: +1:

: +1:

ها ها انا ايضا. سيكون أفضل شيء هو القدرة على وصف الأوامر المخصصة في التكوين لكل برنامج

: +1:

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

+1

ذات صلة: # 179

+1

إجراء +1 آخر لهذا ، لأنني أرغب في رؤية تطبيق Unicorn بدون تعطل يعمل بشكل جيد في المشرف

ومع ذلك ، أعتقد أن المشكلة أكبر من مجرد وجود مشرف يدعم خيار التكوين لإشارة إعادة التشغيل. للحصول على مناقشة شاملة راجع (http://blog.nicolai86.eu/posts/2012-11-28/zero-downtime-deployments-with-unicorn-and-supervisord/) والأداة المذكورة (https: // github. com / alphagov / unicornherder / blob / master / unicornherder / herder.py)

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

في حين أن آلية الإشارات (عادةً sigUSR2) لا تمثل تحديًا ، كما أعتقد ، لإضافة مشرف ، فإن المشكلة الأكبر هي رئيسية جديدة حيث لا يعرف المشرف سوى القليل عنها و 2.

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

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

: +1:

+1

+1

+1

+1

+1

+1

+1 لـ HUP البسيط (قاعدة استخدام gunicorn لإعادة التحميل)

+1

+1

+1

سيكون من المفيد حقًا إذا سمح المشرف بإرسال إشارات مخصصة عبر supervisorctl و web control pannel

أيها الناس ، هذا ليس "نام". هذا مفتوح المصدر. هناك قواعد.

قم بإنهاء طلب الميزة وابدأ في ترميزها بأنفسك اللعينة

http://bit.ly/1mlTKy8

لإرسال إشارات مخصصة ، يمكنك استخدام البرنامج المساعد mr.laforge .

هذا مفتوح المصدر. هناك قواعد.

قم بإنهاء طلب الميزة وابدأ في ترميزها بأنفسك اللعينة

بالطبع. ومع ذلك ، فقد رأيت دائمًا أن هذا هو السماح للمساهمين المنتظمين الحاليين بمعرفة الاقتراحات / التحسينات التي يحتاجها مجتمعهم بشدة. علاوة على ذلك ، هناك طلب سحب مفتوح يبدو أنه ينفذ هذا (على الرغم من أنني أفترض أنه سيحتاج إلى تحديث طفيف لأنه تم إجراؤه قبل 11 شهرًا). ربما كان طلب السحب غير مرضٍ ، لكن لا يوجد تعليق عليه للإشارة إلى ذلك.

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

+1

+1

: +1:

+1

+1

+1

: +1:

+1!

+1

+1

أخذت PR # 228 وقمت بتحديثه لإنشاء علاقات عامة بناءً على أحدث ماجستير: # 477. آمل أن يكون هذا مفيدًا.

كما ذكر fschulze بالفعل ، توفر حزمة

supervisorctl kill HUP nginx

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

أضفت دعم الواجهة الأمامية (supervisorctl) إلى رقم 477 الآن. يشبه هذا:

supervisor> help signal
signal <signal name> <name>           Signal a process
signal <signal name> <gname>:*        Signal all processes in a group
signal <signal name> <name> <name>    Signal multiple processes or groups
supervisor> signal HUP dog:3 dog:4
dog:3: signalled
dog:4: signalled
supervisor> signal HUP dog:*
dog:1: signalled
dog:0: signalled
dog:3: signalled
dog:2: signalled
dog:4: signalled
supervisor> signal USR1 dog:1 dog:2
dog:1: signalled
dog:2: signalled

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

• تطبيق يتكون من تطبيق PHP يعمل على Apache وتطبيق ويب flask / gunicorn وعدد قليل من عمليات عامل الكرفس.
• لقد جمعت هذه في مجموعة عمليات المشرف. تم تغيير التكوين وأريد إعادة تشغيلهم جميعًا.
• في هذه الحالة ، يجب أن أرسل SIGUSR1 إلى Apache ، و SIGHUP إلى عملية gunicorn ، و SIGTERM إلى عمال الكرفس.

سيكون من الجيد أن تكون قادرًا على إصدار supervisorctl graceful myapp:* ويعلم المشرف الإشارة التي يجب إرسالها في كل حالة ، بينما يتخلف عن "إعادة التشغيل" العادية إذا لم يكن متاحًا. يمكن القيام بذلك عن طريق السماح بتضمين "إشارة رشيقة" اختيارية في تكوين البرنامج:

[program:gunicorn]
command=gunicorn wsgi:app -c conf/gunicorn.py
directory=/myapp
autostart=true
autorestart=true
gracefulsignal=HUP

+1 على اقتراح adnam

+1 على هذا الطلب ، بغض النظر عن تفاصيل التنفيذ. أنا مهتم باستخدام مرفق إشارة USR2 لـ nginx (http://nginx.org/en/docs/control.html#upgrade) (نعم ، نقوم بتشغيل nginx تحت إشراف!) للقيام بتحديثات nginx. للأسف ، هذا لا يعمل حاليًا لأن إرسال إشارة USR2 إلى nginx (على سبيل المثال: خارج سياق المشرف) يخلق عملية رئيسية جديدة لـ nginx والتي ليست تابعة للمشرف.

تحديث: شاهدت للتو سحب # 477 ... ستنجح هذه الفكرة

+1 نأمل في إعادة التحميل بأمان

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

مشرف تثبيت apt-get
روايتي هي:
$ dpkg -l | grep -i Supervisor
الثاني المشرف 3.0b2-1

أعد تشغيل البرنامج
إعادة تشغيل اسم البرنامج
بمعنى آخر

مشرف ctl إعادة تشغيل نموذج الطلب
شكل الطلب: توقف
شكل الطلب: بدأ

+1 لإعادة التحميل بشكل رائع ، حيث يمكننا بالفعل اختيار الإشارة الرائعة لإرسالها :)

+1

+1

+1

+1

+1

+1

يوجد 390 شوكة لهذا الغرض. هل يعرف أحد ما إذا كان هناك شخص يقوم بتنفيذ هذا التغيير؟

تحرير: يبدو أن https://github.com/fedosov/supervisor لديه التغيير ، على الرغم من أنني لم أختبره بنفسي حتى الآن.

+1

+1

+1

+1

+1

+1

+1 ... يجب أن نقيم حفلة في 22 نوفمبر.

+1. سأحضر الشمبانيا

+1 لدعم الإشارة والإغلاق / إعادة التشغيل.

كان انطباعي الأول أنه عندما يتلقى المشرف بعض الإشارات للعمل كوكيل وإرسال نفس الإشارة إلى عمليات التحكم. لكن الإشارات المرسلة إلى المشرف لا تتعلق بكيفية تواصل المشرف مع العمليات الخاضعة للرقابة.

منذ المشرف 3.2 يمكنك إرسال أي إشارة لعملية فرعية كما هو موضح أعلاه .

شكرًا ، لقد رأيت ذلك ، لقد قرأت أيضًا جميع التعليقات ضمن طلب السحب https://github.com/Supervisor/supervisor/pull/477 وأنا فضولي لمعرفة كيف سيختار المشرف (أو لا) لدعم التدحرج / إعادة تشغيل رشيقة.

إذا كان برنامجك foo يدعم إعادة التشغيل السهلة من خلال تلقي الإشارة SIGUSR2 ، فعندئذٍ يمكنك استخدام الأمر supervisorctl signal sigusr2 foo بدلاً من الأمر supervisorctl restart foo .

يبدو تطبيق signal في # 477 رائعًا - أعتقد أنه يجب أن يكون كافياً لما يريده معظم الأشخاص في هذا الموضوع. نتطلع إلى استخدامه أخيرًا: +1:

mnaberez أقترح إعادة فتح هذه المشكلة ، لأن الإصلاح المقترح في # 477 غير صحيح على الإطلاق لحالات الاستخدام المطلوبة هنا. سأحاول تلخيص وشرح ما أعنيه:

الفكرة هي أن الاسم المستعار الشائع بالاسم graceful أو reload أو شيء من هذا القبيل يجب أن يكون قابلاً للتكوين ليعني _ "إرسال إشارة عشوائية إلى العملية تحت الإشراف" _. والسبب هو أن البرامج المختلفة تستخدم إشارات مختلفة لهذه الإجراءات ، عادةً ما تكون واحدة من HUP أو USR1 أو USR2 ، ومعاني مختلفة محددة لكل إشارة. من خلال السماح لكود الطرف الثالث (مثل البرامج النصية مسؤول النظام لإدارة ملفات التكوين) بتحديد الإشارة التي يريدون إرسالها ، فإنك _تسرب تفاصيل التنفيذ إلى البرنامج النصي للطرف الثالث_ . لا يهتم الطرف الثالث بأي إشارة يتم إرسالها _ إنه يريد فقط أن يقول للمشرف _ "مرحبًا ، لقد غيرت ملف تكوين التطبيق هذا ، لذا افعل كل ما تحتاجه لإخبار هذه العملية بإعادة تحميل تكويناتها." _

أقترح بشدة أن التكوين والأمر الأكثر فائدة لحالة الاستخدام هذه سيكون شيئًا مثل:

[program:foo]
stopsignal=TERM
restartsignal=HUP
reloadsignal=USR2

supervisor restart foo # this is a hard restart
supervisor reload foo # this is a graceful reload

مرة أخرى ، تنفذ الأدوات المختلفة إشاراتها بشكل مختلف ، والفكرة هي أن المشرف يجب أن يجرد هذه الاختلافات بدرجة معقولة. على سبيل المثال ، في nginx ، إعادة التشغيل الرائعة هي SIGHUP: http://nginx.org/en/docs/control.html ولكن في Apache ، إعادة التشغيل الثابت هي SIGHUP وإعادة التشغيل الرائعة هي SIGUSR2: https://httpd.apache.org/ docs / current / stopping.html وفي الوقت نفسه ، في PHP-FPM ، لا توجد إعادة تشغيل صعبة (يمكنك SIGTERM والبدء من جديد) ولكن إعادة التشغيل الرائعة هي أيضًا SIGUSR2.

ما هو مهم حقًا هو توفير طريقة لتجريد تعيينات الأوامر إلى الإشارة هذه والسماح لمسؤولي النظام بتكوين تكوينات مشرف التطبيق مرة واحدة ، ثم إعادة استخدام الأوامر في مكان آخر دون الحاجة إلى تذكر أن nginx يحتاج إلى HUP ولكن Apache يحتاج إلى USR2 في كل مكان نصوص الأتمتة الأخرى الخاصة بهم.

mnaberez أقترح إعادة فتح هذه المشكلة أيضًا ، ولا أعتقد أن supervisorctl signal sigusr2 foo مفيد لإعادة تشغيل رشيقة.
عملية foo (pid: 60900) على سبيل المثال تحت تحكم المشرف ، نرسل إشارة sigusr2 إليها لإعادة التشغيل السلس ، وتستقبل العملية (pid: 60900) إشارة sigusr2 ، وسوف تتفرع أو تنفذ عملية فرعية (pid: 60901) مع بعض المعلمات الإضافية مثل المستمعين النشطين ، ثم هذه العملية الفرعية ستغلق العملية الرئيسية (pid: 60900) بإرسال SIGTERM إليها ، ثم الخروج من العملية الأب (pid: 60900). ولكن الآن سوف يقوم المشرف بإعادة بدء العملية أيضًا ، قد تبدأ العملية الجديدة (pid: 60902) التي بدأها المشرف بالفشل بسبب عنوان منفذ الشبكة المستخدم بالفعل بواسطة العملية 60901. ولكن 60901 لن يخضع لتحكم المشرف.

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

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

بالنسبة لحالة الاستخدام الخاصة بك مع fork exec ، قد تبحث في cgroups على Linux ، لأنها تتيح لك إدارة شبكة فرعية من العمليات معًا.

sodabrew ربما أنت على حق ، في الواقع ، أعتقد أن المشرف يجب ألا يراقب العملية فقط من خلال معرف العملية ، بل يمكن أن تكون المراقبة من خلال اسم العملية مفيدة أيضًا。

def monitor_process(key_word, cmd):
    if check_process_by_name(key_word):
        return

    sys.stderr.write('process[%s] is lost, run [%s]\n' % (key_word, cmd))
    subprocess.call(cmd, shell=True) 

تطبيق بسيط لهذا ، يمكننا تشغيله تحت crontab.

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

لا يراقب zsounder Supervisor عن طريق pid ، في حد ذاته ، فهو يراقب عن طريق العلاقة بين الوالدين والطفل. يرجى قراءة http://supervisord.org/subprocess.html لمعرفة المزيد عن تصميمه. من فضلك من فضلك لا تسرق هذا الموضوع لاقتراح أفكار جديدة حول إدارة عملية UNIX.

sodabrew أرى الآن ، ths

علامة