<p>يبدأ المشرف جميع العمليات في نفس الوقت</p>

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

mnaberez إذا كانت هناك مشكلة مفتوحة لهذا ، يجب عليك نشر الرابط حتى نتمكن من العثور عليه.

أحتاج أيضًا إلى القدرة على بدء العمليات بترتيب معين.

يمكن للنهج القائم على الحدث أن ينجح. على سبيل المثال ، إذا كان لديّ [program:agent] و [program:client] يمكنني الاشتراك مع العميل لبدء التشغيل عندما يرسل الوكيل حدث started . بشكل افتراضي ، إذا لم يشترك البرنامج في أي حدث ، فسيبدأ عند بدء supervisord .

+1

+1

+1

+1 ، هذه قضية رئيسية.

+1

+1

+1

+1

+1

: +1:

+1

+1

+1

يجب ان يملك

هل هناك تبعية في المشرف؟ إذا لم يكن كذلك ، فلماذا؟

+1

+1

+1

+1

+1

لا أرغب في إضافة أي ضغط محسوس ، لكنني سأكون +1 في نفس الميزة (تبعيات العملية). :-)

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

+1

+1

+1. ربما خيار لتحويل عملية التحميل بشكل متزامن.

: +1:

+1

: +1:

+1

+1

أي شخص لديه أفكار تنفيذية أخرى حول هذا؟ أنا أفكر في الجري فيه لأنه لا يبدو أن أي شخص آخر يهتم.

+1

tomislacker حسنًا ، IMHO الحل الأفضل هو جعل التبعية حلالا على طريقة الدمى. إذا كان بإمكاني أن أرى جيدًا ، فإن أبسط نوع طوبولوجي باستخدام DFS يجب أن يكون أكثر من كافٍ. ثم أضف الحقل "needstarted" (أو "waitforstarted" ، أو ما شابه). سيتم إصلاح هذه المشكلة بالمناسبة.

(عدل) حسنًا ، لست متأكدًا مما سيحدث إذا كان لديك A -> B -> C ( A يعتمد على B ، إلخ) ، سيحاول شخص ما إيقاف B . هل يجب إيقاف A أيضًا؟ حسنًا ... / يعتمد / ...

: +1:

نظرًا لأن الجميع يبدو أنهم بحاجة / يريدون القيام بذلك بطريقة مختلفة قليلاً - ماذا عن مسار مختلف قليلاً؟ بدلاً من محاولة التعبير عن التبعيات مباشرة في توجيه التكوين ، ماذا عن إضافة توجيه لبرنامج نصي "مساعد" بدلاً من ذلك ، ومثالين من المساعدين الذين يناسبون 2-3 حالات استخدام عامة بمتطلبات مختلفة كما أشار kgadek ؟

إليك مثال جيد لتوضيح ما أعنيه:
http://www.serfdom.io/docs/recipes/event-handler-router.html

هناك بعض الأشياء للقيام بهذا النوع من الأشياء بسهولة في bash ،
https://github.com/progrium/pluginhook

وبالتأكيد لا يمكنك التقليل من دقة عبارة "شعرت برغبة في كتابتها بلغة بيثون" (أو أي لغة أخرى يختارها المسؤول)
https://github.com/garethr/serf-master

يبدو لي أن هذا سيكون فوزًا معقولًا للجميع دون استهلاك الكثير من وقت المطور على المشرف نفسه.

مهلا،

نموذج الأقنان يبدو واعدًا جدًا. يبدو أن وجود مجموعة من البرامج النصية بدلاً من معالج واحد فقط مناسبًا (على سبيل المثال ، التحقق من قسمين قبل البدء)

لذلك ، يمكنك تحديد معالج لمعرفة ما إذا كانت العملية / المجموعة: x "can_be_started" ، وإذا كانت جميع البرامج النصية ترجع 0 ، فهذا جيد. يبدو أنه صحيح؟

Imho هذا يجعل "الأولوية" عفا عليها الزمن ، هل أنا مخطئ؟

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

+1 آخر لهذا

+1. لكل تأخير العملية سيكون كافيًا.

لقد تمكنت من التغلب على هذا قليلاً. سريع و قذر.

# Deal with updating our repositories.
supervisorctl start source-code-deploy

# Check for the oneshot process to complete.
while ! supervisorctl status source-code-deploy | grep -q 'EXITED'; do sleep 1; done
# Wait for the while loop to break out signalling success.

# Start the late boot process, now that the deployment is complete.
supervisorctl start system-boot-late

# Check for the oneshot process to complete.
while ! supervisorctl status system-boot-late | grep -q 'EXITED'; do sleep 1; done
# And now we should become EXITED to supervisord and any other tasks relying on the above.

+1

+1

مرحبا،
أود أن أجري هذا في الأسابيع المقبلة ، اسمحوا لي أن أعرف إذا كان هناك أي شخص آخر يعمل على ذلك.

تميل محاولة بدء العديد من العمليات في نفس الوقت تمامًا إلى دفع الآلات إلى الحد الأقصى وفي بعض الأحيان إلى أبعد من ذلك.

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

لسوء الحظ ، هناك عدة طرق لتنفيذ مثل هذه الميزة وإيجاد أفضلها قد يستغرق بعض الوقت.

vladfr ربما يمكننا التعاون في هذا الأمر.

أول شرخ لي "قذر" في ذلك:
https://github.com/liutec/supervisor/commit/eab7cc1e04ad49768593183e8134298604459827
(أنا حقًا لا أحب الاضطرار إلى النوم بهذه الطريقة.)

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

في وضعي ، الهدف هو أن أكون قادرًا على جعل المشرف يدير حوالي 240 برنامجًا متميزًا قد يتطلب بعضها أكثر من مثيل واحد.

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

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

لقد فكرت في كل من حل kamilion بالإضافة إلى الحل المقدم من mnaberez (تشغيل تلقائي) ولكن للأسف لا شيء ينتج في الواقع "startdelay" قابل للتهيئة بسهولة.

+1 إذا كان المشرف لديه "تحكم في التسلسل" فسيكون ذلك رائعًا ، والآن يعتمد كافكا على Zookeeper وما إلى ذلك ولا يمكن للمشرف استخدامه كما نرغب.

+1

أنا أستخدم المشرف لبدء مجموعة من مثيلات qemu الغريبة (لدورة المترجمين) وبعضها يتم تشغيله بسرعة من تلقاء نفسه ولكن يستغرق وقتًا طويلاً إذا بدأ مرة واحدة. سيعمل شيء "تأخير البدء" البسيط على ما يرام: وضع السكون لعدد الثواني المحدد بعد بدء هذه العملية قبل الانتقال إلى المرحلة التالية في القائمة. لا أعرف بالضبط كيف قررت طلب هذه (لا يبدو أن الكلمة الرئيسية ذات الأولوية تطلب بدقة بقدر ما أستطيع أن أعرف من المربعات التي تم إنشاؤها) ولكن مهما كانت ، القدرة على التأخير لبضع ثوان بعد كل عملية من شأنه أن يساعد مجموعة كاملة في حالتي. إذن: +1: بالتأكيد. مرتين ، في الواقع. :-)

أعتقد أن خيار startdelay سيكون مفيدًا جدًا. لدي مشرف لإدارة خادم AMQP وبعض المستهلكين. ينفّذ بعض المستهلكين نومًا قبل البدء ، وبعضهم يتكرّر أثناء محاولة الاتصال / الخطأ / تسلسل السكون (تطبيقات مختلفة). أعرف الحد الأقصى للوقت الذي يحتاجه خادم AMQP للبدء ، لذا فإن إضافة خيار startdelay للمستهلكين من شأنه أن يتجنب تلك الاختراقات القبيحة.

أعتقد أن هذا قد يكون مفيدًا جدًا في العديد من المواقف.

بعد التحقق من الكود ، لا أرى أي مشكلات في BC ، كما أن سلوك supeervisor هو نفسه عند استخدام القيمة الافتراضية.
لا أطيق الانتظار حتى يتم دمج هذا .

+1 لدعم التبعية

+1

+1

+1

+1

+10 ؛)

+1.

يجب إعادة تسمية هذه المشكلة ، لأنني لا أعتقد أن startsecs مناسب هنا. أشعر أن OP ربما أساء تفسير ما يعنيه startsecs ، معتقدًا أنه تأخير قبل بدء العملية.

بدايات

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

+1

+1

ميزة مهمة
+1 كذلك

+1

+1

+1

+1

+1

حل بسيط أستخدمه:

[program:uwsgi]
command=bash -c 'sleep 5 && uwsgi /etc/uwsgi.ini'

+1

+1

هل لدى أي شخص أفكار حول كيف يمكننا حل هذه المشكلة بطريقة أكثر مسؤولية؟ ماذا لو كان هناك أمر يمكن استدعاؤه للتحقق من حالة _ "عبر الإنترنت" _ للعملية؟ مثل:

[program:myapp]
command=/usr/local/bin/myapp-microservice
checkcommand=curl -s http://localhost:54321/v1/_ping
checkfreq=1
checktimeout=3
startsecs=5

المثال أعلاه قد يعني:

1. سيتم تشغيل command كالمعتاد
2. سيتم تنفيذ checkcommand كل checkfreq ثانية بعد الاستدعاء أعلاه حتى startsecs ، ربما بالاقتران مع checktimeout ، يتسبب في إحباط أو إرجاع الأمر 0 .

_ مثال: إذا كانت كل مكالمة إلى checkcommand تستغرق <= 3 ثوان ، checkfreq=1 ، checktimeout=3 ، و startsecs=5 ؛ يتم تشغيل checkcommand + 1.0s ، وإذا فشلت ، فإن + 5.0s ، والتوقف يشير إلى أن الخدمة قد فشلت في نهاية الطلب الثاني checkcommand ._

1. إذا أدى أي استدعاء checkcommand إلى إرجاع حالة خروج 0 ، فإن الخدمة تعتبر عبر الإنترنت.
2. إذا لم checkcommand حالة خروج 0 بعد startsecs ، أو توقف آخر استدعاء محتمل checkcommand لـ >=checktimeout ثانية ، يعتبر بدء الخدمة بمثابة فشل ويفترض أن المنطق "عادي" قد تم وضعه بالفعل. _ (ضع علامة على الخدمة على أنها فاشلة ، وإخراج نفس محتوى السجل ، وما إلى ذلك ...) _

يبدو لي أننا نريد حل المشكلة لكننا لم نصفها جيدًا بما يكفي في هذه المشكلة. الإجابة غير المدققة هي بالتأكيد التأكد من عدم استدعاء الخدمات ذات الأولويات المختلفة حتى _max (startecs) _ لجميع الخدمات ذات الأولوية الأعلى. لكن ألا نطلب ذلك فقط على أمل أن نكون قادرين على تصميم النتيجة المرجوة بشكل فضفاض بدلاً من أن نكون قادرين على التحقق من صحتها في الطريق إلى هناك؟

: +1:

tomislacker أعتقد أن تصميم الرقصات الفضفاض بالنسبة للعديد من الاستخدامات هو حالة مقبولة بنسبة 90٪ حتى لو كان التحقق الكامل هو حالة 100٪.

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

: +1:

+1 أحتاج هذا

tomislacker هذه فكرة جيدة وسهلة الاستخدام لأنك تحتاج فقط إلى ملف التكوين الحالي.
لكن كيف تتعامل مع التبعية الفعلية؟ إذا كان my_program يعتمد على Postgres ، فأنا أتحقق من ذلك في أمر التحقق لبضع مرات وآمل أن يبدأ؟

للتعبير عن تبعية ، أعتقد أنك تريد تشغيل checkcommand قبل الأمر الفعلي.

tomislacker أفضل وجود تبعيات بسيطة بين البرامج

[program:A]
command=/usr/local/bin/A

[program:C]
command=/usr/local/bin/C
dependson=A

ودع المستخدم يقرر ما إذا كانت البرامج ستتحقق من الظروف الأكثر تعقيدًا. على سبيل المثال: يمكننا إدخال [program:B] لإجراء فحص معقد للتأكد من أن A يعمل بشكل صحيح ؛ وتفشل إن لم يكن. لذلك ، يبدأ A . يعتمد B على A لذا سيبدأ فقط عندما يرى المشرف أن A هو RUNNING . عندما يبدأ B ، سيجري تحليله ويفشل إذا لم يعمل A بشكل صحيح. يبدأ C فقط عند تشغيل B (أو عند التشغيل بنجاح).

لا يغطي اقتراحي الميزات الإضافية التي تقترحها ، مثل عدد الشيكات وتوقيت تلك الفحوصات ومتى يجب الاستسلام ؛ لكني أؤيد أيضًا إعطاء المشرف بعض الميزات المشابهة لـ Cron بحيث يسهل تحديد برامج مثل B :

[program:A]
command=/usr/local/bin/A

[program:B]
command=curl -s http://localhost:54321/v1/_ping
dependson=A
startretries=3
restartintervalsec=5

[program:C]
command=/usr/local/bin/C
dependson=B

أنا أؤيد أيضًا إعطاء المشرف بعض الميزات المشابهة لـ Cron

الرجاء مراجعة الرد في # 635. لقد تم النظر في هذا بإسهاب من قبل مطوري المشرفين في الماضي وتقرر أن وظيفة تشبه cron خارج نطاق هذا المشروع. آسف.

: +1: للحصول على طريقة لتقديم تنفيذ متسلسل بطريقة مجدية.

استخدام شيء مثل startuppriority سيكون طريقة قوية جيدة للقيام بهذا IMO.

+1

klahnakoski في مثالك الأول ، تعني C اعتمادًا على A أن المشرف يحتاج إلى معرفة أن A جاهز. في الوقت الحالي ، يعرف فقط أنه بدأ.

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

+1

+1

+1 ؟؟ هذا من مايو 2012 ، أعتقد أن المشرف لن يكون له تبعيات أبدًا.

شخص ما يمكن أن يقترح بدائل مع إدارة التبعيات؟

+1 ، سيجعل هذا الأشياء أكثر أناقة

+1

+1

+1

+1 ، إنه لأمر محزن أن هذا غير ممكن بعد 3 سنوات ، باستخدام وحدات systemd في الوقت الحالي

 .----------------.  .----------------. 
| .--------------. || .--------------. |
| |      _       | || |     __       | |
| |     | |      | || |    /  |      | |
| |  ___| |___   | || |    `| |      | |
| | |___   ___|  | || |     | |      | |
| |     | |      | || |    _| |_     | |
| |     |_|      | || |   |_____|    | |
| |              | || |              | |
| '--------------' || '--------------' |
 '----------------'  '----------------' 

أو من فضلك أضفه.

+1

+1

+1

+1

+1

+10086

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

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

+1

+1

+1

+1

+1. 2016 الآن ...

+1

+1

+1

+1

أيها الرجال ، يرجى استخدام الزر "أعجبني" في الموضوع الأصلي بدلاً من تعليق +1 القديم :) هذا ما صنعه Github من أجله.

شكرا!

أيها الرجال ، يرجى استخدام الزر "أعجبني" في الموضوع الأصلي بدلاً من تعليق +1 القديم :) هذا ما صنعه Github من أجله.

+1: القزم:

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

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

مرحبًا mnaberez ، كنت أتساءل ما حالة ميزة التبعية العملية. ذكرت في عام 2012 أنه كان على قائمة المهام؟ هل ما زال هذا قادمًا؟

كنت أتساءل ما حالة ميزة التبعية العملية. ذكرت في عام 2012 أنه كان على قائمة المهام؟ هل ما زال هذا قادمًا؟

إنه موجود في قائمة المهام ( TODO.txt ) ولا تزال هذه المشكلة مفتوحة. لا أعتقد أن أي مطورين يعملون عليه حاليًا.

+1

هل هذا حقا صعب التنفيذ في المشرف؟ كنت أتساءل عما إذا كانت هناك أدوات أخرى مماثلة للمشرف توفر هذه الميزة؟

+1

+1

+1

+1

+1

أي تحديثات؟ عندما نحصل على هذه الميزة ، سيكون ذلك بمثابة فوز كبير للمشرف على تطبيقنا.

أعتقد أن المشرف يستخدم في الغالب كمدير بدء خفيف الوزن ، بدلاً من حل نظام الرفع الثقيل (مبتدئ ، sysv-init ، ...) ، ولكن حيث يدير systemd تبعيات بدء الخدمة جيدًا ولا يزال المشرف يفتقر إلى هذه الميزة منذ الإبلاغ عن هذه المشكلة في عام 2012

لماذا لا يستطيع بعض المطورين هنا تنفيذ تبعية بسيطة مثل؟ هل هذا المشروع خارج المشرف

https://fedoramagazine.org/systemd-unit-dependencies-and-order/

Wants=sshd-keygen.service
After=network.target sshd-keygen.service

: +1:

اهلا جميعا!

أخيرًا كان لدي بعض الوقت وجربت هذه المحاولة. يؤدي هذا إلى تنفيذ "يعتمد على" كخيار تكوين لكل من [البرنامج] و [المجموعة]. يمكنك تحديد البرامج والمجموعات الأخرى على أنها تبعيات ، وسيتأكد المشرف من أنها ستبدأ قبل البرنامج.

مثال على التكوين:

[program:a]
command=a

[program:monitord]
command = ./monitord.sh
dependson=a
startsecs=5

[group:monitoring]
programs=c1,c2
dependson=monitord,a

[program:c1]
command = bash c1.sh
dependson=anotherprogram ; this doesn't matter because c1 is part of a group
autorestart=true

[program:c2]
command = bash c2.sh
autorestart=true

سيضمن هذا التكوين أمر البدء التالي:

1. أ
2. monitord
3. مجموعة المراقبة ، والتي ستبدأ c1 و c2

لاحظ أن البرنامج: c1 يعتمد على = anotherprogram
نظرًا لأن c1 جزء من مجموعة ، فإن قيمته تعتمد على قيمة المجموعة. في رأيي ، يجب أن يعتمد أعضاء المجموعة على نفس الأشياء.
اي افكار هنا؟

يرجى الاطلاع على التغييرات ، ولا تتردد في مراجعة الفرع "يعتمد على 122" للتجول. لا تزال هناك أشياء يجب القيام بها (الأقسام الدائرية ، واختبارات الإنهاء ، وما إلى ذلك) ولكن أولاً ، أريد بعض التعليقات!

https://github.com/Supervisor/supervisor/compare/master...vladfr : يعتمدon_122؟ قم بتوسيع = 1

شكرا لكم مقدما.

آسف للخطأ خلق # 776

فقط لتلخيص دلالات systemd المشار إليها في https://github.com/Supervisor/supervisor/issues/122#issuecomment -227241447:

• Requires= يسرد هذا التوجيه أي وحدات تعتمد عليها هذه الوحدة بشكل أساسي. إذا تم تنشيط الوحدة الحالية ، فيجب أيضًا تنشيط الوحدات المدرجة هنا بنجاح ، وإلا ستفشل هذه الوحدة. تبدأ هذه الوحدات بالتوازي مع الوحدة الحالية افتراضيًا.
• Wants= هذا التوجيه مشابه لـ يتطلب = ، لكنه أقل صرامة. سيحاول Systemd بدء تشغيل أي وحدات مدرجة هنا عند تنشيط هذه الوحدة. إذا لم يتم العثور على هذه الوحدات أو فشل في البدء ، ستستمر الوحدة الحالية في العمل. هذه هي الطريقة الموصى بها لتكوين معظم علاقات التبعية. مرة أخرى ، هذا يعني التنشيط الموازي ما لم يتم تعديله بواسطة توجيهات أخرى.
• BindsTo= هذا التوجيه مشابه لـ يتطلب = ، ولكنه يتسبب أيضًا في توقف الوحدة الحالية عند إنهاء الوحدة المرتبطة.
• Before= لن يتم بدء تشغيل الوحدات المدرجة في هذا التوجيه حتى يتم تمييز الوحدة الحالية على أنها بدأت إذا تم تنشيطها في نفس الوقت. هذا لا يعني وجود علاقة تبعية ويجب استخدامه مع أحد التوجيهات المذكورة أعلاه إذا كان ذلك مطلوبًا.
• After= ستبدأ الوحدات المدرجة في هذا التوجيه قبل بدء الوحدة الحالية. هذا لا يعني وجود علاقة تبعية ويجب إنشاء واحدة من خلال التوجيهات المذكورة أعلاه إذا كان ذلك مطلوبًا.
• Conflicts= يمكن استخدام هذا لسرد الوحدات التي لا يمكن تشغيلها في نفس الوقت مع الوحدة الحالية. سيؤدي بدء وحدة بهذه العلاقة إلى إيقاف الوحدات الأخرى.

من https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files#unit -section-directives

هذه المجموعة الفرعية من الأوامر قوية للغاية ، وأعتقد بشدة أن الاعتماد الجيد - شجرة التبعية + جيل الأحداث الذي ستحتاجه لتنفيذ أي من هذه التوجيهات يجعل الباقي منها مباشرًا تمامًا.

vladfr (https://github.com/Supervisor/supervisor/issues/122#issuecomment-228416456)

نظرًا لأن c1 جزء من مجموعة ، فإن قيمته تعتمد على قيمة المجموعة. في رأيي ، يجب أن يعتمد أعضاء المجموعة على نفس الأشياء.
اي افكار هنا؟

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

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

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

+1

+1 ، الطريقة القديمة: ابتسامة:

+1 بلز

افحص هذا:
https://mmonit.com/monit/documentation/monit.html#SERVICE-DEPENDENCIES

وهل هناك سبب منطقي لعدم دمج هذا ؟! لقد مرت 4 سنوات وعشرات الأشخاص يطلبون هذه الميزة ... أنا واحد منهم. هذا امر محبط.

مرحبا! واو ، الناس مهتمون حقًا بهذا.

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

بمعنى آخر ، لن يحدث هذا: "في هذه الحالة ، يمكن بدء العديد من أعضاء المجموعة في وقت أبكر من عضو واحد يعتمد على عملية إضافية." - ب / ج لا أستطيع أن أبدأ فقط بعض أعضاء المجموعة.

ومع ذلك ، أنا لا أعارض الدمج ، لأنه يجعل الأمر واضحًا للغاية من التكوين أي خدمة لها التبعية الفعلية.

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

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

شكرا لك!

vladfr أرى ، هذا جيد ، إنه مجرد تحسين بعد كل شيء. شكرا على ملاحظاتك.

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

بشكل عام ، إذا كان لديك توجيه واحد فقط DEPENDS ، فإن دلالات monit -style تبدو أكثر ملاءمة (مع الترجمة المناسبة لحالات التشغيل supervisord ، والسماح للتوجيه بالإشارة لكل من الأعضاء والمجموعات على أنها تبعيات):

https://mmonit.com/monit/documentation/monit.html#SERVICE -DEPENDENCIES

صيغة الجملة التابعة هي ببساطة:

يعتمد على الخدمة [، الخدمة [، ...]]
حيث الخدمة عبارة عن اسم إدخال خدمة تحقق مستخدم في ملف monitrc الخاص بك ، على سبيل المثال apache أو datafs.

يمكنك إضافة أكثر من اسم خدمة من أي نوع أو استخدام أكثر من عبارة تابعة في الإدخال.

سيتم فحص الخدمات المحددة في بيان تابع أثناء عمليات الإيقاف / البدء / المراقبة / عدم المراقبة.

إذا تم إيقاف الخدمة أو عدم مراقبتها ، فسوف تتوقف / لا تراقب أي خدمات تعتمد على نفسها.

في حالة بدء الخدمة ، سيتم بدء تشغيل جميع الخدمات التي تعتمد عليها هذه الخدمة قبل بدء هذه الخدمة. في حالة فشل بدء بعض الخدمة ، لن يتم بدء الخدمة ذات المتطلبات الأساسية ، ولكن سيتذكر أنه يجب أن تبدأ وستعيد محاولة الدورة التالية.

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

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

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

لقد تم اقتراح أن يكون الإيقاف / إعادة التشغيل يدويًا ، على سبيل المثال ، يتم تطبيق dependson كتقييد للبدء فقط. هذا ما يحدث الآن: بعد تشغيل برنامج dependson ، يكون مستقلاً: إذا كان A يعتمد على B ، لا يتم إيقاف A عند إنهاء B. هذا مذكور في المستندات.

فيما يلي بعض نقاط المناقشة ، ورحب بالتعليقات .

1. المشرف: ابدأ سيحترم الأقسام. هل تشعر أن هناك حاجة لإضافة تجاوز لمكالمات RPC؟ يمكن أن تتلقى عملية process.spawn حجة لتخطي فحص deps. يمكن أن يكون هذا تكوينًا في قسم [supervisorctl]. يمكننا حتى تضمين هذا في قسم [المشرف].
2. هل نريد إطلاق حدث ما عندما يتعذر على البرنامج البدء بسبب قسم لم يتم الوفاء به؟
3. فيما يلي مثال على رسالة WARN لوحدة لم يتم تلبيتها ؛ هل هذا جيد كتحذير؟ يمكنني رؤيته على أنه DEBUG ، لأنه نوعًا ما غير مرغوب فيه ، وهذه الرسالة متوقعة.

2016-08-08 19:21:00,419 WARN process 'tom' cannot start - group 'cats' depends on processes which are not started yet: ['mouse', 'night']

إذن mnaberez كيف ينظر إليك كل هذا حتى الآن؟

إذن mnaberez كيف ينظر إليك كل هذا حتى الآن؟

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

mnaberez شكرًا لك ، سأفكر في ذلك بعض الشيء! في الوقت الحالي ، تنتقل العملية مباشرة إلى حالة خطأ (إنهاء غير طبيعي).

بالنسبة للسجل ، كان هذا شيئًا شخصيًا منذ حوالي 18 شهرًا حتى الآن ، لذلك إذا تم اعتباره للدمج ، فهو مكافأة. على أي حال ، يبدو أنه مرشح لـ 4.0.

+1

+1

+1

vladfr أعتقد أنه في فرع المشرف الخاص بك ، فإن تعيين "يعتمد" على أن تكون عضوًا في الفصل GroupProcessConfig سيكون خيارًا أفضل. لأنه من الأسهل استدعاء "removeGroup ()" تكراريًا في "rpcinterface.py".

متحمس جدا ~

نعم ، أعتقد أنني شعرت بذلك في مرحلة ما ولكني غيرتها للسماح بذلك
دمج الأقسام على مستوى المجموعة. لم ألق نظرة على rpc حتى الآن ولكن لا بد لي من ذلك ،
شكرا على الاقتراح!

في الأحد ، 28 أغسطس 2016 ، الساعة 15:19 كتب FakerInHeart [email protected] :

متحمس جدا ~

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/Supervisor/supervisor/issues/122#issuecomment -242971739 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAM-h4JlTLaoxoMLEJRkNLBr_ZoOOmZzks5qkXy0gaJpZM4AAzaa
.

vladfr سيتم نقل الأوامر التي تدخلها في سطر أوامر supervisorctl إلى "استدعاءات الوظائف" إلى وظائف الفئة في rpc. وسيقوم rpc أخيرًا باستدعاء وظائف الأعضاء الخاصة بمشرف الفصل في "supervisord.py".

عدد كبير جدًا من المستخدمين ، وقليل جدًا من المطورين. أورز

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

FAKERINHEART لقد حاولت بالفعل كتابة مشرف آخر باستخدام golang ، لأنني فقط بحاجة إلى جزء من وظيفة المشرف ، وخاصة صفحة مدير الويب للمشرف. لا يزال قيد التقدم https://github.com/codeskyblue/gosuv

+1

+1

+1

تحرير: أنا أستخدم حاليًا مرافق يدعم طلب الخدمة / التبعيات.

لقد حاولت تخصيص "المشرف" لتلبية التبعيات بين البرامج ، والتي تعتمد جزئيًا على الرموز المقدمة من vladfr . ومع ذلك ، عندما أقرأ الكود المصدري للإصدار الأصلي لـ "المشرف" ، أعتقد أن هناك شيئًا غير ممتاز لبنية "المشرف". لقد وجدت أن الوحدة الأساسية لتكوين البرنامج الفرعي في "المشرف" سيتم نقلها إلى "مجموعة التكوين" (processGroupconfig) ، بغض النظر عما إذا كان مفتاح التكوين الخاص بها هو "برنامج" (مجموعة متجانسة) أو تم دمجه في "مجموعة" ( مجموعة غير متجانسة) في ملف التكوين.
وبالنسبة لكائن فئة "المشرف" وفي حلقة الانتقال الخاصة به ، فإنه يعتمد على "مجموعة مجموعة العمليات الفرعية" (process_groups) التي تم إنشاؤها من "مجموعة التكوين" (processGroupconfig) التي ذكرتها أعلاه. أعتقد أن وحدة "مجموعة التكوين" كبيرة جدًا بحيث لا تكون مفيدة لـ "المشرف" لإدارتها. علاوة على ذلك ، من الصعب إدراك التبعيات بين البرامج الفرعية ، إذا كانت هذه الوظيفة ستكون في خطتك في المستقبل.
أعتقد أنه سيكون من الأفضل أن تكون الوحدة الأساسية للبرنامج الفرعي هي "برنامج التكوين" (قد يُطلق عليها "processProgramconfig") ، ويتم استخدام "مجموعة التكوين" (processGroupconfig) فقط لتجميعهما معًا.

+100

كنت حقًا في حاجة إلى هذا ، ولم يكن صوت مستمع الحدث صعبًا جدًا لذا كتبت واحدة. لن تحل مشكلة الجميع ، ولا تبعيات ، إنها مجرد بدء تشغيل مرتب:
https://pypi.python.org/pypi/ordered-startup-supervisord/

+1 ...

FAKERINHEART يعتذر عن الرد المتأخر. أعتقد أنك على الفور: ما وصفته في تعليقك الأخير

سيتم نقل الوحدة الأساسية لتكوين البرنامج الفرعي في "المشرف" إلى "مجموعة التكوين" (processGroupconfig) ، بغض النظر عما إذا كان مفتاح التكوين هو "برنامج" (مجموعة متجانسة) أو تم دمجه في "مجموعة" (مجموعة غير متجانسة) في ملف التكوين.

هذه هي المشكلة بالضبط ، ولماذا هذه المهمة ليست مباشرة.
هل وجدت تحسينًا أو حلًا آخر هنا؟ أود التحدث أكثر حول هذا الموضوع ، اضربني.

+1

+1

+1

+1

+1

+1

+1

+1

+1

بالنسبة لأولئك المهتمين ، لقد تناولت هذه الميزة في https://github.com/julien6387/supvisors من خلال قاعدة "بدء_تسلسل" ملف النشر.

تم تصميم Supvisors للتطبيقات الموزعة ولكن "إذا كان بإمكانك تحريك الجبال ، فيمكنك تحريك التلال".
إنه يعمل مع مثيل مشرف واحد.

+1

+1

+1

+1

+1

+1

https://github.com/FAKERINHEART/supervisor
راجع ملف Introduction.txt واستخدم الفرع dev-3.3.1-sr1.
لقد كان لدي هذا الفرع مع ميزات التبعية بين المجموعات (البرامج) للمشرف ، والتي تعتمد جزئيًا على الرموز التي اقترحها vladfr .
إذا وجدت أي أخطاء ، من فضلك قل لي في الوقت المناسب.

+1

+1

تم فتح هذه القضية منذ عام 2012 ، فهل يمتلكها أحد؟ من الواضح أنه مهم للعديد من المستخدمين ؛ هل يوجد إجماع بين المشرفين المساهمين؟

+1

+1

+1

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

تم فتح هذه المشكلة منذ عام 2012 وأصبح من السخف أن تظل التذكرة مفتوحة لهذه المدة الزمنية.

+1 ...

+1

+1

+1

لمعلوماتك: الرد على مشكلة لمجرد قول "+1" يرسل إشعارًا إلى كل شخص مشترك في المشكلة. يمكنك فقط الرد على التعليق الأولي للمشكلة باستخدام 👍 emoji بدلاً من ذلك.

تضمين التغريدة

لمعلوماتك: الرد على مشكلة لمجرد قول "+1" يرسل إشعارًا إلى كل شخص مشترك في المشكلة.

لكن هذا نوع من النقطة ، أليس كذلك؟ أنا مشترك في هذا العدد ، وأنا مهتم جدًا برؤية الأشخاص الآخرين المهتمين جيدًا. هذه القضية عمرها أكثر من 5 سنوات. إنه لأمر جيد أن تقوم بإجراء اختبار ping للمطورين لتذكيرهم بلطف بأن الناس ما زالوا مهتمين. من الجيد أيضًا لمن اشتركوا ، أن يؤكدوا أن هناك أيضًا آخرين يهتمون ، وليس هذا الشخص فقط ؛)

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

أستطيع أن أؤكد أن بدء العمليات بترتيب معين هو مطلب مهم. عذرًا ، لم أتمكن من تأكيد ذلك مسبقًا. هل سيتم تنفيذها الآن؟

عند مشاركة حل لهذه المشكلة ، قد يختلف عدد الأميال التي قطعتها. أثناء انتظار إصلاح هذا ، قمت بنقل معظم أجزاء بنيتنا التحتية بالاعتماد على هذه الميزة إلى Docker / Kubernetes. عادةً ما تحتوي أطر عمل Docker المتنوعة (تكوين عامل ميناء ، سرب ، Kubernetes ، إلخ) على آليات للتحكم في طلب بدء التشغيل (غالبًا مع مجموعة التحديات الخاصة بها). لذلك ، إذا كنت تنتظر إصلاح هذا ، فربما تستخدمه كذريعة للتلاعب بمشروع إنشاء عامل ميناء بسيط لمعرفة ما إذا كان يوفر نهجًا بديلاً لهذه المشكلة. أدرك أن هذا قد ينطبق فقط على جزء صغير من المستخدمين الذين ينتظرون إصلاح هذا.

مرحبا جميعا

لقد قمت بتطبيق مكون إضافي للحدث مع دعم لبدء الخدمات بالترتيب المحدد بواسطة الخدمات التابعة.
الق نظرة على هذا المثال .

https://github.com/bendikro/supervisord-dependent-startup

يمكن أيضًا أن يكون البرنامج النصي wait-for-it.sh لمجتمع Docker بديلاً عن المكون الإضافي الرائع bendikro . من الأسهل قليلاً إعداده إذا كان لديك نظام أتمتة معقد يديره ، على الرغم من أنه ليس جميلًا مثل المكون الإضافي الأصلي:
https://github.com/vishnubob/wait-for-it

أيضًا ، يمكنك انتظار عمليات معينة مثل هذه:

# Wait until PHP FPM is up to start, since supervisord like to start everything at once...
# See
while [[ $(ps -aux | grep "[p]hp-fpm: master process") == "" ]];
do
    echo "Waiting for PHP FPM to come up..."
    sleep 2s
    if [[ $(ps -aux | grep "[p]hp-fpm: master process") != "" ]]; then
        echo "PHP FPM looks to be started, continuing with Icinga daemon initialization"
        ps -aux | grep "[p]hp-fpm: master process"
    fi
done

لدي القليل فقط ، لذلك استقرت على هذه الطريقة

شيء أدركته للتو هو أنه ، لنفترض أنني استخدم supervisor لاستضافة قاعدة البيانات الخاصة بي وخادمي. تحتوي خدمة الخادم على autorestart=true طالما أنه يفشل في الاتصال بقاعدة البيانات ، فسيتم إعادة المحاولة بشكل صحيح. لذلك ينجح الأمر.

+1

+1

+1

الرجاء النقر فوق علامة الإعجاب على المشاركة الأصلية بدلاً من مجرد التعليق على "+1". تحصل على آمالي عندما أرى إشعارًا: د

على خيار حل هذه المشكلة هو تحديد في Supervisor.conf أن البرنامج سيحصل على قيمة تشغيل تلقائي للخطأ على سبيل المثال:

[البرنامج: اختبار]
تشغيل تلقائي: "خطأ"
الأمر = "/ home / user / test"

الخطوة الثانية هي استخدام bash script لبدء مثال Supervisorctl:

محطة جنوم - "المشرف"
محطة جنوم -E "supervisorctl"
النوم 10
Gnome-Terminal -e "اختبار بدء المشرف"

* شكراً لأفينير جيدرون لإعطائي الفكرة

مرحبا،
لدي البرنامج النصي أدناه في ملف supervisor.cnf:

[البرنامج: zookeeper]
ستارتكس = 60
الدليل = / التطبيق
الأمر = / bin / bash -c "java -jar zoo.jar"
الأولوية = 1
تشغيل تلقائي = صحيح
autorestart = صحيح

[البرنامج: kafka]
ستارتكس = 60
الدليل = / التطبيق
الأمر = / bin / bash -c "java -jar kaf.jar"
stdout_logfile = / var / log / supervisor /٪ (program_name) s.log
stderr_logfile = / var / log / supervisor /٪ (program_name) s.log
الأولوية = 999
تشغيل تلقائي = صحيح
autorestart = صحيح

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

@ kumarshorav11 إنها ليست جميلة ، لكن ما أفعله هو مراقبة العملية لتظهر أولاً (كل ما يحتاج إلى الانتظار) /. هذا مثال فقط.

httpd.conf

[program:httpd]
command=/opt/supervisor/httpd_supervisor
autorestart=true
startretries=3
# Start only after PHP FPM
priority=2
# redirect output to stdout/stderr and do not use a regular logfile
stdout_logfile=/dev/stdout
stdout_logfile_maxbytes=0
stderr_logfile=/dev/stderr
stderr_logfile_maxbytes=0

/ opt / supervisor / httpd_supervisor:

#!/bin/bash

# Wait until PHP FPM is up to start, since supervisord likes to start everything at once...
# See https://github.com/Supervisor/supervisor/issues/122

echo -e "\n==> Starting httpd"
# PHP FPM
while [[ $(ps -aux | grep "[p]hp-fpm: master process") == "" ]];
do
    echo "Waiting for PHP FPM to come up to start httpd..."
    sleep 2s
    if [[ $(ps -aux | grep "[p]hp-fpm: master process") != "" ]]; then
        echo "PHP FPM looks to be started, continuing with Icinga daemon initialization"
        ps -aux | grep "[p]hp-fpm: master process"
    fi
done

# Another project had this, but we won't be using systemd
# service httpd start
/usr/sbin/httpd

# Allow any signal which would kill a process to stop server
trap "service httpd stop" HUP INT QUIT ABRT ALRM TERM TSTP

while pgrep -u apache httpd > /dev/null; do sleep 5; done

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

إذن هناك بالفعل https://github.com/jasoncorbett/ordered-startup-supervisord ، لماذا لم يتم دمج هذا في المشرف الرئيسي ، هل هناك أي سبب لعدم إصلاح ذلك؟

تحرير: شوكة أخرى مماثلة https://github.com/bendikro/supervisord-dependent-startup

أي حل أنيق؟

أنا جميعًا مع هذه الميزة

لقد كان من الممتع تتبع هذه المشكلة طوال هذه السنوات ، لكني أخيرًا ألغيت اشتراكي: الفرح:

حالتي هي أنني أريد فقط التحكم في أمر الإيقاف عندما لا يكون يدويًا في فترة تحكم المشرف ، A > B ، C ،
حل بسيط: في برنامج نصي ، اكتبهم واحدًا تلو الآخر ،
supervisorctl stop A:*
supervisorctl stop B:* C:*
supervisorctl start A:* B:* C:*
أو إذا كان هناك غير B ، C ، افعل مثل هذا grep
supervisorctl status | grep -v '^A:*' | grep -v '^B:*' | grep -v '^C:*' | awk -F':' '{print $1":*"}' | xargs | supervisorctl restart