Celery: إعادة تشغيل مشكلات الكرفس وملف تكوين مشرف أفضل

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

إذا قمت بتثبيت الوحدة النمطية setproctitle ، فيجب على الكرفس الإبلاغ عن نوع العملية في قوائم ps ، فهل يمكنك القيام بذلك للتحقق من نوع العملية التي تم إنشاؤها؟

( easy_install setproctitle )

من المحتمل أن يكون تعيين المهلة على 600 أمرًا جيدًا. هل هناك أي إعداد لما لا نهاية (ربما مع تحذير إذا استغرق الأمر وقتًا طويلاً)؟ عندما يُقتل celeryd عن طريق TERM (وهي إشارة إيقاف التشغيل المفضلة) ، فإنه يتوقف عن تلقي الرسائل وينتظر انتهاء المهام المنفذة حاليًا. وأعتقد بالنسبة لمعظم التطبيقات ، إنهاء منتصف التنفيذ أمر غير مقبول.

أما بالنسبة لعملية التفريخ: فإن setproctitle ومراقبة معرفات العملية كانت مفيدة. انها ليست عملية التبويض. تظل عمليات العامل على قيد الحياة عند قتل العملية الأبوية.
هذه محاكاة لإعادة تشغيل المشرف مع القتل اليدوي وعدم انتهاء المهلة:

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6101 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6108 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 nadovmeste:~# kill 6101 & kill -9 6101 &

ملاحظة:

 4976 ?        Ss     0:00 /usr/bin/python /usr/bin/supervisord --pidfile /var/run/supervisord.pid
 5422 ?        S      0:01  \_ [celerybeat] --schedule=/var/lib/celery/celerybeat-schedule-nadovmeste --loglevel=INFO                                                             
 6867 ?        Sl     0:00  \_ [celeryd.MainProcess] Running... (--loglevel=INFO)                                                           
 6875 ?        S      0:00      \_ [celeryd.PoolWorker-1]                                                                                       
 6108 ?        S      0:00 [celeryd.PoolWorker-1]       

لم أتمكن من إعادة إنتاج هذا إلا باستخدام مثل هذا السباق الاصطناعي بين kill و kill -9 . في بعض الأحيان يُقتل العامل بشكل صحيح. يبدو أن المشكلة خاصة بالمشرف لأنه عندما أبدأ استخدام الكرفس من وحدة التحكم ، لا يحالفني الحظ في إعادة إنتاجه.

تمكنت من إعادة إنتاج هذا باستخدام البرامج النصية التي تم تشغيلها بواسطة وحدة التحكم بعد عدة محاولات:

/home/nadovmeste/envs/nadovmeste/bin/python /home/nadovmeste/src/nadovmeste/manage.py celeryd -B --loglevel=INFO&

ثم في جلسة طرفية أخرى:

nadovmeste:~# ps -afx

 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash
 9343 pts/2    Sl     0:00          \_ [celeryd.MainProcess] Running... (-B --loglevel=INFO)                                                           
 9350 pts/2    S      0:00              \_ [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00              \_ [celerybeat]     

nadovmeste:~# kill 9343 & kill -9 9343

nadovmeste:~# ps -afx

 4526 ?        Ss     0:00  \_ sshd: root@pts/1 
 4529 pts/1    Ss     0:00  |   \_ -bash
 9366 pts/1    R+     0:00  |       \_ ps -afx
 6450 ?        Ss     0:00  \_ sshd: root@pts/2 
 6452 pts/2    Ss+    0:00      \_ -bash    
 ...
 9350 pts/2    S      0:00 [celeryd.PoolWorker-2]                                                                                          
 9355 pts/2    S      0:00 [celerybeat]

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

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

إذا كنت أقوم باختبار بعض مهام الكرفس محليًا واستخدمت الخيار -B في بعض الأحيان لا يتم إنهاء العملية عند استخدام ctrl-c.

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

نعم ، أنا أدير أحدث فرع رئيسي. لقد رأيت التزام إصلاح الأخطاء الخاص بك وآمل أن يساعد ولكن يبدو أنه لا يساعد في حالتي: يبدو أن أحدث الكرفس يتصرف بنفس الطريقة. لكن من الممكن أن تكون المشكلة الأولية قد تم حلها - أنا أتحقق من ذلك فقط بقتل فوري. لا يمكنني التفاف يدي حولها الآن :) لا يمكن تكرار مشكلة ctrl-c مع الإعداد الخاص بي.

لذا فإن تقرير الخطأ مبسط: http://gist.github.com/401028 . النتائج هي نفسها دائمًا (ليس في بعض الأحيان). لدي بعض المهام الدورية وبعضها غير دوري. المهام بسيطة ولا تستغرق الكثير من الوقت حتى تنتهي. هل من الأخطاء التي يعالجها الأطفال البقاء على قيد الحياة بعد قتل العملية الرئيسية؟ إذا كان الأمر كذلك ولا يمكنك إعادة إنتاجه ، فسأحاول تقديم الحد الأدنى من المشروع.

يعتبر سلوك قتل نبض الكرفس أمرًا مثيرًا للاهتمام: عندما أقتل معلقًا (؟)

kmike ما زلت لا أستطيع التكاثر بالأوامر أعلاه. ربما لأنني على OS X ، أو ربما كنت تستخدم Python 2.5؟ (أنا أقوم بتشغيل 2.6.1)

يمكن تشغيله بـ --loglevel=DEBUG? ويمكن أن يوفر بعض المعلومات حول مكان توقفه.

تبدأ عملية الكرفس بالعملية الرئيسية ، لذلك أفترض أن العملية الرئيسية تنتظر
لخروج الكرفس قبل أن يقتل عمليات البركة المتبقية.

اعتقدت أن العملية الرئيسية قد قُتلت: فهي غير مرئية في قائمة العمليات. ليس لديك خبرة كبيرة في إدارة العمليات بالرغم من ذلك.

كان إعدادي هو Debian Lenny + python 2.5.

سأحاول تشغيل celeryd باستخدام --loglevel = DEBUG وإعادة إنتاجه على جهاز macbook الخاص بي.

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

لقد حاولت للتو إعادة الإنتاج على Debian Lenny باستخدام python 2.5 ، وهو يعمل تمامًا هناك.
حاولت القتل مع كل من TERM و INT.

اسأل ، شكرا لك على المساعدة.

أعتقد أنه تم حل المشكلة الأولية مع زيادة مهلة المشرف وإصلاح الأخطاء. كانت المحاكاة غير صحيحة لأنني استخدم أوامر kill -9 وهم يرسلون إشارة KILL بدلاً من TERM. مع TERM يتم قتل عمليات الإشارة بشكل صحيح.

يستخدم المشرف إشارة TERM لذا يجب أن يكون كل شيء على ما يرام.

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

آه! متأسف جدا. لم أقرأ القضية بعناية كافية. نعم! هذا بالضبط ما يحدث عندما تقتلها مع SIGKILL. لا يمكن التقاط إشارة 9 ، لذلك لا يمكننا فعل أي شيء حيال AFAIK.

إذا كنت لا تزال تواجه مشكلات في إنهاء عمال الكرفس لديك ، فقد تحاول تعيين stopasgroup=true قبل زيادة stopwaitsecs .