Gunicorn: कोई निकास संकेत न होने के बावजूद "बूटिंग कार्यकर्ता" असीम रूप से लूपिंग कर रहा है

ssh -डॉकर कंटेनर में डालने से मुझे यह त्रुटि मिली:

Illegal instruction (core dumped)

शायद गनिकोर्न को त्रुटियों को निगलने के बजाय इस तरह से सतह पर लाना चाहिए, या उन्हें अलग तरीके से संभालना चाहिए? यकीन नहीं है, मैंने सोचा कि मैं इसे बढ़ाऊंगा क्योंकि यह किसी और की मदद कर सकता है!

समस्या की सूचना देने के लिए धन्यवाद!

यदि आप यह पता लगा सकते हैं कि यह कहाँ होता है, तो यह बहुत मददगार होगा।

श्रमिकों के बाहर निकलने पर शायद हम लॉगिंग जोड़ सकते हैं। आमतौर पर, कार्यकर्ता स्वयं लॉग इन करता है, लेकिन अगर यह बहुत अचानक मारा जाता है तो ऐसा नहीं होगा।

कोई चिंता नहीं!

ऐसा लगता है कि स्पासी के साथ कोई समस्या है जिसे मैंने अभी इस धागे में जोड़ा है: https://github.com/explosion/spaCy/issues/1589

वैसे भी, यह SIGILL का कारण बन रहा है क्योंकि strace पुष्टि करता है:

--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7ff48bbe6cea} ---
+++ killed by SIGILL (core dumped) +++
Illegal instruction (core dumped)

मुझे लगता है कि यह अच्छा होगा यदि गनिकोर्न इसकी पहचान कर सकता है और कार्यकर्ता को फिर से शुरू करने के बजाय एक त्रुटि लॉग कर सकता है, लेकिन tbh मुझे इस बारे में बहुत कम पता है कि निकास कोड कैसे काम करते हैं!

कुछ निकास कोडों के निश्चित रूप से विशेष अर्थ होते हैं और हम शायद उन्हें लॉग कर सकते हैं।
http://tldp.org/LDP/abs/html/exitcodes.html

बढ़िया है! इसके अतिरिक्त यदि निकास कोड एक आरक्षित निकास कोड नहीं है (जैसे कि यह मामला), तो यह अच्छा होगा यदि इसे लॉग किया जा सकता है (बिना किसी स्पष्टीकरण के) तो यह स्पष्ट है कि कार्यकर्ता वास्तव में समाप्त हो रहा है

मेरे पास इसी तरह का मुद्दा है, जब मैं http अनुरोध करता हूं तो गनिकोर्न हमेशा नए कार्यकर्ता को बूट कर रहा है। मुझे कोई प्रतिक्रिया वापस नहीं मिलती है, यह हमेशा नए कार्यकर्ता को रीबूट करता है। दो http अनुरोधों से स्ट्रेस लॉग:

select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=510, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=32} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 510
lseek(8, 0, SEEK_CUR)                   = 0
close(8)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 840340})     = 1 (in [3], left {0, 840338})
read(3, ".", 1)                         = 1
read(3, 0x7f2682025fa0, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-q4aa72u7", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 8
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-q4aa72u7", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-q4aa72u7")       = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(8, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(8, 0, SEEK_CUR)                   = 0
lseek(8, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 558
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 37381}[2017-12-28 17:50:23 +0000] [558] [INFO] Booting worker with pid: 558
) = 0 (Timeout)
select(4, [3], [], [], {1, 0}loading test-eu-ovh settings
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0}
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=499, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=31} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 499
lseek(7, 0, SEEK_CUR)                   = 0
close(7)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 450691})     = 1 (in [3], left {0, 450689})
read(3, ".", 1)                         = 1
read(3, 0x7f2682067de8, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-5x9a40ca", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 7
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-5x9a40ca", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-5x9a40ca")       = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(7, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(7, 0, SEEK_CUR)                   = 0
lseek(7, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 579
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 8144}[2017-12-28 17:50:30 +0000] [579] [INFO] Booting worker with pid: 579
)  = 0 (Timeout)
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0

मुझे एक ही समस्या का सामना करना पड़ रहा है, gunicorn sync कार्यकर्ता प्रकार के लिए सेकंड के भीतर दोहराया जा रहा है। कार्यकर्ता टाइमआउट को 900 पर सेट करने से मदद नहीं मिल रही है।

कार्रवाई से पहले मेरे लोड में, मैं एडब्ल्यूएस एस 3 से डेटा डाउनलोड कर रहा हूं। विभिन्न फाइलों को डाउनलोड करने में लगभग 1 मिनट 10 सेकंड का समय लगता है।

@ सारा -02 गनिकोर्न लॉन्च करने के लिए आपकी कमांड लाइन क्या है?

@benoitc gunicorn --pythonpath /src -b 0.0.0.0:$SERVICE_PORT --workers=1 -k sync -t $SERVICE_TIMEOUT flask_endpoint:app
यहां उपस्थित

@ सारा -02 धन्यवाद।

क्या वास्तव में पुराने कर्मचारी बाहर निकल रहे हैं या उन्हें ऑनलाइन रखा गया है और नए श्रमिकों को जन्म दिया गया है? डीबग लॉग भी क्या दिखाता है?

लॉग को बोटोकोर लॉग के साथ मिलाया जाता है, लेकिन यह कुछ इस तरह है

[INFO] Booting worker with pid:  a
[INFO] Booting worker with pid:  b
[INFO] Booting worker with pid:  c

लेकिन क्या मजदूर मारे गए हैं? कमांड ps ax|grep gunicorn क्या लौटाता है?

@benoitc

एक सवाल हालांकि, हम 2 gunicorn प्रक्रियाओं को क्यों देखते हैं, जब कार्यकर्ता सीमा 1 पर सेट की जाती है? क्या एक मास्टर और एक कार्यकर्ता है?

1 आर्बिटर प्रक्रिया (मास्टर) है और एन कार्यकर्ता आपको संसाधित करते हैं :)

तो जब भी कोई कार्यकर्ता सही बूट करता है तो आप कमांड चलाते हैं? यदि ऐसा है तो ऐसा लगता है कि पुराने कार्यकर्ता को मार दिया गया है, एक नया पैदा हुआ है। मैं जांच करूंगा।

@ सारा -02 एक आखिरी बात, यह भी डोकर में हो रहा है?

@benoitc docker-compose यह अपेक्षा के अनुरूप काम कर रहा है, लेकिन जब मैं उसी कोड को Openshift पर डाल रहा हूं, तो मुझे यह त्रुटि दिखाई देती है। स्मृति आवश्यकता को बढ़ाना ठीक हो गया, लेकिन जब मैं docker-compose माध्यम से एप्लिकेशन चलाता हूं तो यह limited मेमोरी का उपयोग कर रहा है।

बस एक अद्यतन, मेरे लिए समस्या वास्तव में एक स्मृति त्रुटि थी और स्मृति समस्या ठीक होने पर ठीक की गई थी।

@benoitc
डॉकटर में 5 गनिकोर्न वर्कर को स्पॉन करने की कोशिश करते समय मुझे एक ही समस्या का सामना करना पड़ रहा है।
@ सारा-02
आपने स्मृति त्रुटि होने के कारण की पहचान कैसे की?

@ गुलशन-गौरव 2 चीजों ने मेरी मदद की:
मैंने अपने पॉड को सौंपी गई मेमोरी को बढ़ाया और क्रैश होना बंद कर दिया। दूसरा, हमने अपने Openshift Zabbix लॉग की जाँच की।

@ सारा-02
यहां तक ​​​​कि मेरे स्टेजिंग पॉड पर फाइलें + मॉडल जिन्हें मैं मेमोरी में लोड कर रहा हूं, उनकी मात्रा 50Mb है, इसलिए 5 श्रमिकों के लिए 2GB मेमोरी पर्याप्त होनी चाहिए।

@ गुलशन-गौरव आप किस मुद्दे का सामना कर रहे हैं? वहाँ 5 प्रक्रिया होने से अच्छा लगता है ....

मेरी भी यही समस्या थी। मुझे सटीक समस्या का पता नहीं चला, लेकिन एक बार जब मैंने अजगर 3.5 से 3.6 में अपग्रेड किया तो इसे हल कर दिया गया।

मुझे डॉकर कंटेनर में एक ही समस्या का सामना करना पड़ रहा है। जब भी मैं किसी ऐसे एंडपॉइंट को कॉल करता हूं जो विफलता का कारण बनता है, लेकिन अपवाद या त्रुटि Gunicorn की लॉग फ़ाइलों में आउटपुट नहीं होती है, तो Gunicorn हर बार एक नए कार्यकर्ता को बॉट करता रहता है। जिन चीजों को मैं प्रिंट करने के लिए चुनता हूं वे लॉग हो जाती हैं और फिर अचानक लॉग फ़ाइल सिर्फ "पीआईडी ​​के साथ बूटिंग वर्कर ..." कहती है।

एक कदम जिसने मदद की वह था env वेरिएबल PYTHONUNBUFFERED को जोड़ना। इससे पहले, प्रिंट स्टेटमेंट भी गायब हो जाते थे और गनिकोर्न के लॉग में सहेजे नहीं जाते थे।

ऐप के 2 अन्य एंडपॉइंट सही तरीके से काम करते हैं।

मैं Gunicorn इसके साथ चलाता हूं: gunicorn run:app -b localhost:5000 --enable-stdio-inheritance --error-logfile /var/log/gunicorn/error.log --access-logfile /var/log/gunicorn/access. लॉग --कैप्चर-आउटपुट --लॉग-लेवल डिबग

पहले से ही पायथन 3.6 चल रहा है और शीर्ष के साथ जांच की गई है कि स्मृति कोई समस्या नहीं लगती है।

संपादित करें: ऐसा लगता है कि यह एक पायथन मुद्दा था और एक गनिकोर्न की गलती नहीं थी। कुछ संस्करण विसंगतियां एक निश्चित ऑपरेशन करते समय पाइथन को बिना किसी निशान के मरने का कारण बन रही थीं।

मैं इसी तरह के मुद्दे का सामना कर रहा हूं जहां कार्यकर्ता नोड आते रहते हैं
Booting worker with pid: 17636 । मुझे नहीं पता कि यह पिछले कार्यकर्ता नोड को मार रहा है या पिछले कार्यकर्ता नोड अभी भी मौजूद है। लेकिन गनिकोर्न कमांड लाइन तर्कों में उल्लिखित श्रमिकों की संख्या केवल 3 - -workers=3 । इसके अलावा मैं अजगर संस्करण 3.7 . का उपयोग कर रहा हूँ

मेरे पास स्किकिट-लर्न डिपेंडेंसी का बेमेल था, लेकिन इसे हल करने के बाद भी, मुझे अभी भी वही अनंत कार्यकर्ता आ रहे हैं। मुझे किस प्रकार की पायथन संस्करण विसंगतियों की तलाश करनी चाहिए और उन्हें कैसे पहचानना चाहिए?

मुझे OpenShift के अंदर एक ही समस्या का सामना करना पड़ रहा है।

जैसा कि आप छवि में देख सकते हैं, मैं 6 श्रमिकों का उपयोग कर रहा हूं (मैं 3 के साथ प्रयास कर रहा था)।
मैंने पॉड की मेमोरी बढ़ा दी और यह काम नहीं किया।

बिल्ड कॉन्फिग:

कोई विचार?

धन्यवाद

क्या आप इसे एल्ब के पीछे एडब्ल्यूएस में चला रहे हैं? मैंने एल्ब और गनिकोर्न के बीच nginx प्रवेश करके उस मुद्दे को हल किया

एक ही मुद्दा हो।

flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Starting gunicorn 19.9.0
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Using worker: sync
flask_1  | [2019-02-23 09:08:17 +0000] [8] [INFO] Booting worker with pid: 8
flask_1  | [2019-02-23 09:08:19 +0000] [12] [INFO] Booting worker with pid: 12
flask_1  | [2019-02-23 09:08:19 +0000] [16] [INFO] Booting worker with pid: 16
flask_1  | [2019-02-23 09:08:20 +0000] [20] [INFO] Booting worker with pid: 20
flask_1  | [2019-02-23 09:08:21 +0000] [24] [INFO] Booting worker with pid: 24
flask_1  | [2019-02-23 09:08:22 +0000] [28] [INFO] Booting worker with pid: 28
flask_1  | [2019-02-23 09:08:23 +0000] [32] [INFO] Booting worker with pid: 32
flask_1  | [2019-02-23 09:08:25 +0000] [36] [INFO] Booting worker with pid: 36
flask_1  | [2019-02-23 09:08:26 +0000] [40] [INFO] Booting worker with pid: 40
flask_1  | [2019-02-23 09:08:27 +0000] [44] [INFO] Booting worker with pid: 44
flask_1  | [2019-02-23 09:08:29 +0000] [48] [INFO] Booting worker with pid: 48
flask_1  | [2019-02-23 09:08:30 +0000] [52] [INFO] Booting worker with pid: 52
flask_1  | [2019-02-23 09:08:31 +0000] [56] [INFO] Booting worker with pid: 56
flask_1  | [2019-02-23 09:08:33 +0000] [60] [INFO] Booting worker with pid: 60
flask_1  | [2019-02-23 09:08:34 +0000] [64] [INFO] Booting worker with pid: 64
flask_1  | [2019-02-23 09:08:35 +0000] [68] [INFO] Booting worker with pid: 68
flask_1  | [2019-02-23 09:08:36 +0000] [72] [INFO] Booting worker with pid: 72
flask_1  | [2019-02-23 09:08:37 +0000] [76] [INFO] Booting worker with pid: 76
flask_1  | [2019-02-23 09:08:38 +0000] [80] [INFO] Booting worker with pid: 80
flask_1  | [2019-02-23 09:08:40 +0000] [84] [INFO] Booting worker with pid: 84
flask_1  | [2019-02-23 09:08:41 +0000] [88] [INFO] Booting worker with pid: 88
flask_1  | [2019-02-23 09:08:42 +0000] [92] [INFO] Booting worker with pid: 92
flask_1  | [2019-02-23 09:08:44 +0000] [96] [INFO] Booting worker with pid: 96
flask_1  | [2019-02-23 09:08:45 +0000] [100] [INFO] Booting worker with pid: 100
flask_1  | [2019-02-23 09:08:45 +0000] [104] [INFO] Booting worker with pid: 104
flask_1  | [2019-02-23 09:08:46 +0000] [108] [INFO] Booting worker with pid: 108
flask_1  | [2019-02-23 09:08:47 +0000] [112] [INFO] Booting worker with pid: 112
flask_1  | [2019-02-23 09:08:48 +0000] [116] [INFO] Booting worker with pid: 116
flask_1  | [2019-02-23 09:08:49 +0000] [120] [INFO] Booting worker with pid: 120
flask_1  | [2019-02-23 09:08:50 +0000] [124] [INFO] Booting worker with pid: 124
flask_1  | [2019-02-23 09:08:52 +0000] [128] [INFO] Booting worker with pid: 128

यहां docker-compose.yml :

version: '3'
services:
  flask:
    build: .
    command: gunicorn -b 0.0.0.0:5000 hello:app --reload
    environment:
      - FLASK_APP=hello.py
      - FLASK_DEBUG=1
      - PYTHONUNBUFFERED=True
    ports:
      - "5000:5000"
    volumes:
      - ./:/root

यह किस डॉकर छवि का उपयोग करता है?

@benoitc

[ec2-user@ip-172-31-85-181 web-services-course]$ docker --version
Docker version 18.06.1-ce, build e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
[ec2-user@ip-172-31-85-181 web-services-course]$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

यहां इसके लिए लिंक दिए गए हैं:

• Dockerfile https://github.com/glebmikha/web-services-course/blob/master/Dockerfile
• docker-compose.yml https://github.com/glebmikha/web-services-course/blob/master/docker-compose.yml

पता चला कि यह स्मृति की कमी के कारण हो सकता है। ऐप को उपलब्ध से अधिक मेमोरी की आवश्यकता है।
लेकिन यह सिर्फ धारणा है

बस जानकारी के रूप में: मैंने ठीक यही व्यवहार देखा था जब मेरे पास 3 श्रमिकों के लिए एक गनिकोर्न कॉन्फिडेंस था, लेकिन मैंने एक सिंगल कोर सीपीयू के साथ एक वर्चुअल मशीन में कोड को तैनात किया। फिर, मैंने 2 कोर का उपयोग करने के लिए पर्यावरण को बदल दिया, और जाहिर है कि समस्या गायब हो गई

क्यों 'कार्यकर्ता बाहर निकल रहा है' केवल स्तर की जानकारी पर - एक त्रुटि के परिणाम के अलावा एक कार्यकर्ता बाहर क्यों निकलेगा? मुझे यह पता लगाने में काफी समय लगा कि मेरे वर्कर थ्रेड्स को सिस्टम ओओएम किलर द्वारा मारा जा रहा है, लॉग में कुछ भी नहीं है, सिवाय इसके कि ऊपर कुछ अन्य लोगों द्वारा समय-समय पर 'पीआईडी ​​के साथ बूटिंग वर्कर' की रिपोर्ट की गई है।

@HughWarrington क्योंकि बाहर निकलने वाला कार्यकर्ता जरूरी नहीं कि एक त्रुटि हो। श्रमिकों को सिग्नल या --max-requests जैसे विकल्पों द्वारा समाप्त किया जा सकता है।

@HughWarrington जब कोई कार्यकर्ता असामान्य निकास कोड से बाहर निकलता है तो हम शायद

आप उसके लिए एक टिकट खोल सकते हैं, या एक पीआर योगदान कर सकते हैं जो इस कोड को reap_workers पद्धति में जोड़ता है।

मेरे पास एक ही समस्या थी, और समाधान फली के स्मृति आकार को बढ़ाना था।

एक बड़े स्पासी मॉडल के साथ डॉकर पर गनिकोर्न चलाने में एक ही समस्या थी, यह बिना किसी त्रुटि संदेश के श्रमिकों को पुनरारंभ करता रहा। इसका समाधान डॉकर कंटेनर के लिए मेमोरी बढ़ाना है।

कुबेरनेट्स पर चल रहे जेवेंट (1.4.0) श्रमिकों के साथ नवीनतम (19.9.0) गनिकोर्न पर आज ही इस मुद्दे का सामना करना पड़ा। ऐप एक फाल्कन ऐप है और डॉकर इमेज आधिकारिक पायथन इमेज है जिसका टैग 3.7.3 ।

[2019-07-05 00:07:42 +0000] [8] [INFO] Starting gunicorn 19.9.0
[2019-07-05 00:07:42 +0000] [8] [INFO] Listening at: http://0.0.0.0:5000 (8)
[2019-07-05 00:07:42 +0000] [8] [INFO] Using worker: gevent
[2019-07-05 00:07:43 +0000] [35] [INFO] Booting worker with pid: 35
[2019-07-05 00:07:43 +0000] [36] [INFO] Booting worker with pid: 36
[2019-07-05 00:07:43 +0000] [37] [INFO] Booting worker with pid: 37
[2019-07-05 00:07:43 +0000] [38] [INFO] Booting worker with pid: 38
[2019-07-05 00:07:43 +0000] [41] [INFO] Booting worker with pid: 41
[2019-07-05 00:07:43 +0000] [43] [INFO] Booting worker with pid: 43
[2019-07-05 00:07:43 +0000] [45] [INFO] Booting worker with pid: 45
[2019-07-05 00:07:43 +0000] [49] [INFO] Booting worker with pid: 49
[2019-07-05 00:07:43 +0000] [47] [INFO] Booting worker with pid: 47
[2019-07-05 00:07:49 +0000] [53] [INFO] Booting worker with pid: 53
[2019-07-05 00:07:50 +0000] [54] [INFO] Booting worker with pid: 54
[2019-07-05 00:07:53 +0000] [57] [INFO] Booting worker with pid: 57
[...]

पॉड में निम्नलिखित संसाधन सेटिंग्स थीं:

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

सब कुछ दोगुना करने से समस्या ठीक हो गई।

एक दिलचस्प बात जो हमने देखी वह यह थी कि जब हम होस्ट मशीन पर dmesg को देखते हैं तो हम देख सकते हैं कि यह segfault - libcrypto पर एसएसएल का उपयोग कर सर्वर तक पहुंचने पर है।

ऐसा लगता है कि स्मृति मेरे लिए कोई समस्या नहीं है क्योंकि मैं स्मृति में कोई बड़ा मॉडल लोड नहीं कर रहा हूं। कार्यकर्ता बस दुर्घटनाग्रस्त होते रहते हैं और मुझे कोई त्रुटि संदेश नहीं दिखाई देता है। क्या इसे ठीक करने का कोई तरीका है?

मेरे लिए एक ही समस्या, ठीक करने के लिए कोई विचार? अजगर 3.6.3 गनिकोर्न के साथ 19.9.0

@MrKiven आपका ऐप क्या करता है? क्या आप अनुरोध जैसी सामग्री का उपयोग कर रहे हैं?

क्या कोई इस मुद्दे को पुन: पेश करने का कोई तरीका प्रदान कर सकता है?

यह कई घटकों का प्रबंधक है जो एक पाइपलाइन में निष्पादित होते हैं। उनमें से कुछ उसी मशीन या दूरस्थ मशीनों पर अन्य घटकों के लिए HTTP अनुरोध शुरू कर सकते हैं। पाइपलाइन के कुछ मॉड्यूल समानांतर में निष्पादित किए जा सकते हैं लेकिन उन्हें ThreadPoolExecutor का उपयोग करके निष्पादित किया जाता है। वे किसी भी साझा किए गए ऑब्जेक्ट का उपयोग नहीं करते हैं, लेकिन वे केवल डेटा संरचनाएं उत्पन्न करते हैं जो बाद में एक परिणामी एक में एकत्रित होते हैं।

दुर्भाग्य से मुझे यकीन नहीं है कि हमारे पास मौजूद सिस्टम को उजागर किए बिना मैं एक न्यूनतम उदाहरण एक साथ रख सकता हूं।

अनुरोध धागे के साथ बहुत सी असुरक्षित चीजें करता है जो कभी-कभी एक नई प्रक्रिया को फोर्क करता है। मैं दूसरे क्लाइंट का उपयोग करने की सलाह दूंगा। क्या आप कम से कम उन पंक्तियों को पेस्ट कर सकते हैं जिनका आप अनुरोध करने के लिए उपयोग कर रहे हैं? क्या आप इसकी टाइमआउट सुविधा का उपयोग कर रहे हैं?

उनमें से एक हो सकता है:

try:
     resp = requests.post(self._endpoint, json=request_data)

     if resp.status_code != 200:
          logger.critical("[Error]: status code is {}".format(resp.status_code))
          return None

     response = resp.json()
     return {"intent": response["intent"], "intent_ranking": response["intent_ranking"]}
except ConnectionError as exc:
     logger.critical("[Exception] {}".format(str(exc)))
     return None

धन्यवाद। मैं इससे एक सरल बनाने की कोशिश करूंगा।

यह वैसे भी अच्छा होगा यदि कोई हमें एक पीआर भेज सकता है जो व्यवहार को एक उदाहरण या एक इकाई परीक्षण के रूप में पुन: पेश करता है तो हम सुनिश्चित करते हैं कि हम वास्तव में सही चीज़ को ठीक कर रहे हैं।

सुनिश्चित नहीं है कि यह किसी की मदद कर सकता है, लेकिन डॉकरीकृत फ्लास्क वेबएप चलाते समय मेरे पास एक ही समस्या थी और इसे मेरे डॉकरफाइल की मूल छवि को python:3.6.9-alpine अपडेट करने के लिए हल किया गया था

मेजबान पर Dmesg ने lilibpython3.6m.so.1.0 पर एक segfault दिखाया:

[626278.653010] gunicorn[19965]: segfault at 70 ip 00007f6423e7faee sp 00007ffc4e9a2a38 error 4 in libpython3.6m.so.1.0[7f6423d8a000+194000]

मेरी डॉकटर छवि python:3.6-alpine पर आधारित थी और एक apk update कर रही थी जो अजगर को 3.6.8 पर अपडेट कर रही थी।

जैसा कि कहा गया है कि मूल छवि को python:3.6.9-alpine बदलने से यह मेरे लिए हल हो गया है

फ्लास्क + डॉकर + कुबेरनेट्स चलाने में मुझे एक ही चुनौती का सामना करना पड़ा। सीपीयू और मेमोरी की सीमा बढ़ाने से यह मेरे लिए हल हो गया।

हमारे साथ भी ऐसा ही हुआ था। संसाधन सीमा बढ़ाने से समस्या ठीक हो गई।

यह अचानक मेरे साथ macOS कैटालिना (कंटेनरीकृत नहीं) पर हुआ।

मुझे क्या मदद मिली है:

1. ओपनएसएल स्थापित करना:

brew install openssl

1. इसे मेरे ~/.zshrc चलाना और जोड़ना:

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib:$DYLD_LIBRARY_PATH

स्रोत: https://stackoverflow.com/a/58445755/5811984

मुझे इसी तरह की चुनौती का सामना करना पड़ रहा है और अगर कोई मेरी मदद कर सकता है तो आभारी होंगे।
मेरे पास यही था;

" root@ubuntu-s-1vcpu-1gb-nyc1-01 :~# sudo systemctl status gunicorn.service gunicorn.service - gunicorn daemon लोडेड: लोडेड (/etc/systemd/system/gunicorn.service; अक्षम; विक्रेता प्रीसेट: सक्षम) सक्रिय: सोम 2020-02-24 07:48:04 यूटीसी से सक्रिय (चल रहा है); 44मिनट पहले मुख्य पीआईडी: 4846 (गनिकोर्न) कार्य: 4 (सीमा: 1151) सीग्रुप: /system.slice/gunicorn.service 4846 /होम/ब्राइट/djangoprojectenv/djangoprojectenv/bin/python/home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - ├─4866 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoprojectenv/djangoprojectenv/djangoprojectenv /बिन/गनिकोर्न - 4868 /होम/ब्राइट/djangoprojectdir/djangoprojectenv/bin/python/home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - └─4869 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home /bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - फ़रवरी 24 07:48:04 ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: गनिकोर्न डेमॉन बंद कर दिया। फ़रवरी 24 07:48:04 ubuntu-s-1vcpu -1जीबी-एनवाईसी1-01 सिस्टमडी[1 ]: गनिकोर्न डेमॉन शुरू किया। फ़रवरी 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 गनिकोर्न[4846]: [2020-02-24 07:48:05 +0000] [4846] [जानकारी] गनिकोर्न 20.0.4 फरवरी 24 शुरू करना 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [जानकारी] यहां सुन रहा है: unix:/run/gunicorn .soc फ़रवरी 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 गनिकोर्न[4846]: [2020-02-24 07:48:05 +0000] [4846] [जानकारी] कार्यकर्ता का उपयोग करना: सिंक फरवरी 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4866] [जानकारी] pid के साथ बूटिंग वर्कर: 4866 फरवरी 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4868] [जानकारी] pid के साथ बूटिंग वर्कर: 4868 फरवरी 24 07 :48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4869] [जानकारी] pid के साथ बूटिंग वर्कर: 4869 फरवरी 24 08: 03:41 ubuntu-s-1vcpu-1gb-nyc1-01 गनिकोर्न[4846]: - - [24/फ़रवरी/2020:08:03:41 +0000] "GET/HTTP/1.0" 400 26 "-" "मोज़िला /5.0 (वाई लाइन्स 1-20/20 (END)" क्या कोई इसे ठीक करने में मेरी मदद कर सकता है?

@BrightNana क्या आप dmesg देने की कोशिश कर सकते हैं और देख सकते हैं कि क्या आपके पास कोई गनिकोर्न त्रुटि है?
dmesg | grep gunicorn अन्य त्रुटियों को फ़िल्टर करने में मदद कर सकता है

नमस्ते,
मेरे पास डेबियन 9 में एक ही बग है जब मैं एक सिस्टमड सेवा के रूप में गनिकोर्न प्रदान करना चाहता हूं। अगर मैं इसे सीएलआई से शुरू करता हूं, तो गनिकोर्न त्रुटियों के बिना चलता है।

dmesg | grep gunicorn से निकालें:

journalctl से अंश:
Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1054] [INFO] Booting worker with pid: 1054 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1057] [INFO] Booting worker with pid: 1057 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1060] [INFO] Booting worker with pid: 1060 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1064] [INFO] Booting worker with pid: 1064 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1067] [INFO] Booting worker with pid: 1067 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1070] [INFO] Booting worker with pid: 1070 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1073] [INFO] Booting worker with pid: 1073 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1076] [INFO] Booting worker with pid: 1076 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1079] [INFO] Booting worker with pid: 1079 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1082] [INFO] Booting worker with pid: 1082 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1085] [INFO] Booting worker with pid: 1085 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1088] [INFO] Booting worker with pid: 1088 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1091] [INFO] Booting worker with pid: 1091 Mär 12 07:01:09 build-server gunicorn[828]: [2020-03-12 07:01:09 +0100] [1094] [INFO] Booting worker with pid: 1094
systemctl status से निकालें:
● api.service - API Server for BuildingChallenge served with Gunicorn Loaded: loaded (/etc/systemd/system/api.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 08:26:01 CET; 22min ago Main PID: 8150 (gunicorn) Tasks: 3 (limit: 4915) Memory: 37.7M (high: 100.0M max: 500.0M) CGroup: /system.slice/api.service ├─ 8150 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app ├─28936 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app └─28938 /usr/bin/python3 -Es /usr/bin/lsb_release -a Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28909] [INFO] Booting worker with pid: 28909 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28912] [INFO] Booting worker with pid: 28912 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28915] [INFO] Booting worker with pid: 28915 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28918] [INFO] Booting worker with pid: 28918 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28921] [INFO] Booting worker with pid: 28921 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28924] [INFO] Booting worker with pid: 28924 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28927] [INFO] Booting worker with pid: 28927 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28930] [INFO] Booting worker with pid: 28930 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28933] [INFO] Booting worker with pid: 28933 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28936] [INFO] Booting worker with pid: 28936

आपकी सहायता के लिए धन्यवाद।

मैंने एक पीआर लगाया जो इस प्रकार की स्थितियों को डीबग करने में मदद कर सकता है। क्या कोई देख सकता है?
https://github.com/benoitc/gunicorn/pull/2315

डॉकर के अंदर चल रहे फ्लास्क एप्लिकेशन के साथ मेरा भी यही मुद्दा था। कार्यकर्ता एक बढ़ती हुई प्रक्रिया आईडी के साथ असीमित रूप से पुनः आरंभ कर रहे थे।

मुद्दा मेरे लिए स्मृति से संबंधित था, जब मैंने डॉकर के लिए अनुमत स्मृति को बढ़ाया, तो कार्यकर्ता प्रभावी रूप से पैदा हुए।

@tilgovi , मुझे कोई आपत्ति नहीं है कि आप मेरे परिवर्तनों को अपने पीआर में शामिल करना चाहते हैं क्योंकि आप वहां पहले पहुंचे थे। इसमें सिग्नल के जरिए मारे जा रहे मजदूरों को कवर किया जाएगा।

@mildebrandt मैं एक नज़र

मैं भी अचानक इस व्यवहार को देख रहा हूँ, एक डॉकर कंटेनर के अंदर Gunicorn (20.0.4) + Gevent (1.5.0) + फ्लास्क का उपयोग कर।

[  328.699160] gunicorn[5151]: segfault at 78 ip 00007fc1113c16be sp 00007ffce50452a0 error 4 in _greenlet.cpython-37m-x86_64-linux-gnu.so[7fc11138d000+3e000]

मेरे मामले में, जैसा कि आप देख सकते हैं segfault gevent के कारण हो रहा है। अजीब बात यह है कि इस कंटेनर ने 5 दिन पहले ठीक काम किया था, और तब से कोई भी कोड नहीं बदलता है, किसी भी पुस्तकालय के किसी भी संस्करण को बदल दिया है, और ये सभी विशिष्ट रिलीज पर सेट हैं। मैंने फ्लास्क-मेल को एक निर्भरता के रूप में हटा दिया, जिसने अन्य निर्भरताओं के संस्करणों को थोड़ा बदल दिया होगा।

gevent==1.5.0 से gevent==20.9.0 में अपडेट करने से मेरे लिए समस्या का समाधान हो गया।

@ifiddes आपकी समस्या संभावित रूप से असंबंधित है। आप नवीनतम संस्करण ग्रीनलेट के साथ gevent के पुराने संस्करणों के बीच ABI संगतता समस्या देख रहे हैं। देखें https://github.com/python-greenlet/greenlet/issues/178

आह, धन्यवाद @jamadden। बूटिंग वर्कर्स की अनंत स्पॉनिंग की खोज करते समय यह पोस्ट मुझे मिल सकती थी, लेकिन वह मुद्दा और उस मुद्दे का समय मेरी समस्या के अनुकूल था।

मुझे उबंटू 20.04 सर्वर के साथ एक नई एडब्ल्यूएस मशीन और उसी कोड के साथ एक समान त्रुटि थी जो उत्पादन पर काम करती है।

मशीन को अन्य उत्पादन मशीनों की तरह Ansible का उपयोग करके कॉन्फ़िगर किया गया था।

[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Current configuration:
  config: None
  bind: ['127.0.0.1:8000']
  backlog: 2048
  workers: 1
  worker_class: uvicorn.workers.UvicornWorker
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /var/www/realistico/app
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1001
  group: 1001
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: /var/www/realistico/logs/gunicorn/access.log
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: /var/www/realistico/logs/gunicorn/error.log
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  dogstatsd_tags: 
  statsd_prefix: 
  proc_name: None
  default_proc_name: realistico.asgi:application
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f7ba5fdd550>
  on_reload: <function OnReload.on_reload at 0x7f7ba5fdd670>
  when_ready: <function WhenReady.when_ready at 0x7f7ba5fdd790>
  pre_fork: <function Prefork.pre_fork at 0x7f7ba5fdd8b0>
  post_fork: <function Postfork.post_fork at 0x7f7ba5fdd9d0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f7ba5fddaf0>
  worker_int: <function WorkerInt.worker_int at 0x7f7ba5fddc10>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f7ba5fddd30>
  pre_exec: <function PreExec.pre_exec at 0x7f7ba5fdde50>
  pre_request: <function PreRequest.pre_request at 0x7f7ba5fddf70>
  post_request: <function PostRequest.post_request at 0x7f7ba5f6e040>
  child_exit: <function ChildExit.child_exit at 0x7f7ba5f6e160>
  worker_exit: <function WorkerExit.worker_exit at 0x7f7ba5f6e280>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f7ba5f6e3a0>
  on_exit: <function OnExit.on_exit at 0x7f7ba5f6e4c0>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: None
  raw_paste_global_conf: []
  strip_header_spaces: False
[2020-10-15 15:11:49 +0000] [18068] [INFO] Starting gunicorn 20.0.4
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Arbiter booted
[2020-10-15 15:11:49 +0000] [18068] [INFO] Listening at: unix:/run/gunicorn.sock (18068)
[2020-10-15 15:11:49 +0000] [18068] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-10-15 15:11:49 +0000] [18080] [INFO] Booting worker with pid: 18080
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] 1 workers
[2020-10-15 15:11:51 +0000] [18083] [INFO] Booting worker with pid: 18083
[2020-10-15 15:11:53 +0000] [18086] [INFO] Booting worker with pid: 18086
...
[2020-10-15 15:12:09 +0000] [18120] [INFO] Booting worker with pid: 18120
[2020-10-15 15:12:11 +0000] [18123] [INFO] Booting worker with pid: 18123

सफलता के बिना इस मुद्दे को हल करने की कोशिश में कई बार हारने के बाद (और लॉग पर किसी भी त्रुटि के बिना), मैंने इस हैलो वर्ल्ड के साथ प्रयास किया

ModuleNotFoundError: No module named 'httptools'

httptools इंस्टॉल करने के बाद हैलो वर्ल्ड एप्लिकेशन ठीक काम करता है और अप्रत्याशित रूप से, मेरा एप्लिकेशन भी काम करता है।

मुझे नहीं पता कि त्रुटि क्यों लॉग नहीं की गई थी या यह पुस्तकालय अन्य मशीनों पर क्यों स्थापित किया गया था, लेकिन नई पर नहीं, लेकिन यह मेरे लिए समस्या को ठीक करता है।

क्या यह हाल ही में हुआ था और सभी सीपीयू का उपभोग करके कुबेरनेट्स नोड को नीचे ले गया था। dmesg बारे में संकेत के लिए धन्यवाद मुझे अंततः एक त्रुटि मिली:

[225027.348869] traps: python[44796] general protection ip:7f8bd8f8f8b0 sp:7ffc21a0b370 error:0 in libpython3.7m.so.1.0[7f8bd8dca000+2d9000]

अंत में मेरा मुद्दा https://github.com/python-greenlet/greenlet/issues/178 का एक और उदाहरण था और इसे नवीनतम संस्करण में गनिकोर्न, गीवेंट और ग्रीनलेट को अपडेट करके हल किया गया था।

चूंकि इस प्रकार के अपवाद कोई पायथन लॉग नहीं बनाते हैं, पकड़े नहीं जा सकते हैं, निकास कोड 0 लौटाएं, और जब वे होते हैं तो मशीन को लटका सकते हैं, उन्हें प्रबंधित करना बहुत मुश्किल होता है।

मेरा प्रस्ताव है कि गनिकोर्न इस प्रकृति के तेजी से क्रैश-लूपिंग का पता लगाता है और

• या तो छोड़ दें या नए कामगारों के पैदा होने की दर को सीमित करें
• लोगों को इस मुद्दे पर निर्देशित करने वाला एक उपयोगी संदेश प्रदान करें और https://github.com/python-greenlet/greenlet/issues/178

शायद max_consecutive_startup_crashes डिफ़ॉल्ट रूप से num_workers * 10 होने के साथ?

आइए #2504 में क्रैश लूप फीचर अनुरोध को ट्रैक करें। #2315 में अतिरिक्त लॉगिंग के लिए हमारे पास पीआर भी है। मैं इस मुद्दे को बंद कर दूंगा क्योंकि ऐसा लगता है कि सभी ने अपनी समस्याओं को डीबग कर दिया है और अब हमारे पास भविष्य में दूसरों की मदद करने के लिए कुछ सुविधा अनुरोध और सुधार हैं। सबको धन्यवाद!