Celery: अजवाइन के मुद्दों और बेहतर पर्यवेक्षक विन्यास फाइल को फिर से शुरू करना

KILL सिग्नल प्राप्त करते समय उत्पन्न प्रक्रियाएं वास्तव में अजीब हैं। supervisord के बाहर उपयोग किए जाने पर मुझे वह व्यवहार दिखाई नहीं देता है, तो हो सकता है कि यह इसके कारण कुछ हो?

यदि आप setproctitle मॉड्यूल स्थापित करते हैं, तो सेलेरी को ps लिस्टिंग में इस तरह की प्रक्रिया की रिपोर्ट करनी चाहिए, क्या आप यह जांचने के लिए कर सकते हैं कि किस तरह की प्रक्रिया बनाई गई है?

( easy_install setproctitle )

टाइमआउट को 600 पर सेट करना शायद अच्छा है। क्या अनंत के लिए कोई सेटिंग है (शायद चेतावनी के साथ अगर इसमें बहुत अधिक समय लगता है)? जब celeryd को TERM (जो पसंदीदा शटडाउन सिग्नल है) के माध्यम से मार दिया जाता है तो यह संदेश प्राप्त करना बंद कर देता है और वर्तमान में निष्पादित कार्यों के समाप्त होने की प्रतीक्षा करता है। और मुझे लगता है कि ज्यादातर अनुप्रयोगों के लिए, समाप्ति मध्य निष्पादन स्वीकार्य नहीं है।

प्रोसेस स्पॉनिंग के लिए: सेटप्रोक्टाइटल और प्रोसेस आईडी के लिए देखना मददगार था। यह स्पॉनिंग की प्रक्रिया नहीं है। जब मूल प्रक्रिया समाप्त हो जाती है तो कार्यकर्ता प्रक्रियाएं जीवित रहती हैं।
यह मैन्युअल हत्या और शून्य समयबाह्य के साथ पर्यवेक्षक पुनरारंभ का अनुकरण है:

 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 विकल्प का उपयोग करने के बाद कंसोल-स्टार्ट सेलेरीड के लिए समस्या को पुन: उत्पन्न करने में सक्षम था।

अगर मैं स्थानीय रूप से कुछ सेलेरी कार्यों का परीक्षण कर रहा हूं और मैं -बी विकल्प का उपयोग करता हूं तो कभी-कभी जब मैं ctrl-c का उपयोग करता हूं तो प्रक्रिया समाप्त नहीं होती है।

मैं इसे स्थानीय रूप से पुन: पेश नहीं कर सकता। बीटीडब्ल्यू, क्या आप मास्टर शाखा चला रहे हैं? मैंने अभी एक बग तय किया है जो शटडाउन लटका सकता है। यदि आप इसके साथ परीक्षण कर सकते हैं तो यह अच्छा होगा।

हाँ, मैं नवीनतम मास्टर शाखा चला रहा हूँ। मैंने आपकी बग-फिक्सिंग प्रतिबद्धता देखी और आशा की कि इससे मदद मिलेगी लेकिन ऐसा लगता है कि यह मेरे मामले में मदद नहीं करता है: नवीनतम सेलेरी ऐसा ही व्यवहार करती है। लेकिन यह संभव है कि प्रारंभिक समस्या हल हो जाए - मैं इसे केवल तत्काल मार से जांचता हूं। मैं अब इसके चारों ओर अपना हाथ नहीं लपेट सकता :) मेरे सेटअप के साथ ctrl-c समस्या प्रतिलिपि प्रस्तुत करने योग्य नहीं है।

तो बग रिपोर्ट, सरलीकृत: http://gist.github.com/401028 । परिणाम हमेशा समान होते हैं (कभी-कभी नहीं)। मेरे पास कुछ आवधिक कार्य हैं और कुछ गैर-आवधिक। कार्य सरल हैं और समाप्त होने में अधिक समय नहीं लगता है। क्या यह एक बग है कि मुख्य प्रक्रिया को मारने के बाद बच्चों की प्रक्रिया जीवित रहती है? यदि ऐसा है और आप इसे पुन: पेश नहीं कर सकते हैं तो मैं न्यूनतम परियोजना प्रदान करने का प्रयास करूंगा।

सेलेरीबीट हत्या व्यवहार दिलचस्प है: जब मैं फांसी (?) सेलेरीबीट प्रक्रिया को मारता हूं तो फांसी (?) कार्यकर्ता प्रक्रिया भी बंद हो जाती है।

@kmike मैं अभी भी ऊपर दिए गए आदेशों के साथ पुन: पेश नहीं कर सकता। शायद इसलिए कि मैं OS X पर हूं, या हो सकता है कि आप Python 2.5 चला रहे हों? (मैं 2.6.1 चला रहा हूँ)

इसे --loglevel=DEBUG? के साथ चला सकते हैं यह इस बारे में कुछ जानकारी प्रदान कर सकता है कि यह कहां रुकता है।

सेलेरीबीट प्रक्रिया मुख्य प्रक्रिया द्वारा शुरू की जाती है, इसलिए मुझे लगता है कि मुख्य प्रक्रिया प्रतीक्षा कर रही है
शेष पूल प्रक्रियाओं को मारने से पहले सेलेरीबीट से बाहर निकलने के लिए।

मैंने सोचा था कि मुख्य प्रक्रिया मार दी गई थी: यह प्रक्रिया सूची में दिखाई नहीं दे रही है। हालांकि प्रक्रिया प्रबंधन के साथ ज्यादा अनुभव नहीं है।

मेरा सेटअप डेबियन लेनी + पायथन 2.5 था।

मैं सेलेरीड को --loglevel=DEBUG के साथ चलाने और इसे अपनी मैकबुक पर पुन: पेश करने का प्रयास करूंगा।

हम्म, आप बिल्कुल सही हैं। यह लगभग वैसा ही है जैसे बीट प्रक्रिया पूल प्रक्रियाओं का स्वामित्व लेती है।

मैंने सिर्फ डेबियन लेनी पर अजगर 2.5 के साथ पुन: पेश करने की कोशिश की, और यह वहीं काम करता है।
TERM और INT दोनों के साथ मारने की कोशिश की।

पूछो, मदद के लिए धन्यवाद।

मुझे लगता है कि बढ़ी हुई पर्यवेक्षक टाइमआउट और आपकी बग-फिक्सिंग प्रतिबद्धता के साथ प्रारंभिक समस्या हल हो गई थी। सिमुलेशन गलत था क्योंकि मैं kill -9 कमांड का उपयोग करता हूं और वे TERM के बजाय KILL सिग्नल भेजते हैं। टीईआरएम सिग्नल प्रक्रियाओं के साथ ठीक से मारे जा रहे हैं।

पर्यवेक्षक टीईआरएम सिग्नल का उपयोग करते हैं इसलिए सब ठीक होना चाहिए।

लेकिन जो चीज मुझे थोड़ी डराती है, वह यह है कि शुरुआती बग की जांच नहीं की गई थी। मैं इसे पुन: पेश करने की कोशिश करूंगा और आपको बता दूंगा।

आह! मुझे खेद है। मैंने इस मुद्दे को पर्याप्त ध्यान से नहीं पढ़ा। हां! ठीक ऐसा ही होता है जब आप इसे सिगकिल से मारते हैं। 9 सिग्नल को पकड़ा नहीं जा सकता है, इसलिए इस AFAIK के बारे में हम कुछ नहीं कर सकते।

यदि आपको अभी भी अपने अजवाइन श्रमिकों को समाप्त करने में समस्या हो रही है, तो आप अपना stopwaitsecs बढ़ाने से पहले stopasgroup=true सेट करने का प्रयास कर सकते हैं।