Werkzeug: बंद पाइप पर लिखने के बाद वेर्कज़ेग क्रैश हो जाता है

उत्पादन WSGI सर्वर जैसे Gunicorn या uWSGI का उपयोग करें, Werkzeug dev सर्वर का नहीं।

मेरे पास एक बहुत ही समान समस्या है सिवाय इसके कि मैं विकास के लिए Werkzeug dev सर्वर का उपयोग कर रहा हूं (जो कि, AFAICT, इसका इच्छित उपयोग है), यानी ब्राउज़र के साथ सीधे पोर्ट 5000 से जुड़ा हुआ है।

त्रुटि प्रति घंटे कई बार होती है, जिससे सर्वर के मैन्युअल पुनरारंभ को विकसित होने के लिए मजबूर होना पड़ता है।

यहां एक ट्रेसबैक है:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 659, in inner
    srv.serve_forever()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 499, in serve_forever
    HTTPServer.serve_forever(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 238, in serve_forever
    self._handle_request_noblock()
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 297, in _handle_request_noblock
    self.handle_error(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 295, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 321, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 334, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/SocketServer.py", line 655, in __init__
    self.handle()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 216, in handle
    rv = BaseHTTPRequestHandler.handle(self)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 340, in handle
    self.handle_one_request()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 251, in handle_one_request
    return self.run_wsgi()
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi
    execute(self.server.app)
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 186, in execute
    write(b'')
  File "/Users/fermigier/envs/extranet-spr/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write
    self.send_header(key, value)
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/BaseHTTPServer.py", line 401, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

मैं विकास सर्वर ( debug=True ) के साथ @sfermigier के समान समस्या का अनुभव करता हूं, और एक ही ट्रेसबैक त्रुटि है।

यह व्यवहार आमतौर पर एक बहुत ही साधारण मामले में होता है: आप किसी प्रकार की स्वतः पूर्ण सुविधाओं का उपयोग कर रहे हैं। ब्राउज़र क्वेरी टोकन के लिए एक कनेक्शन शुरू करता है और फिर रुक जाता है और अधिक टोकन के लिए एक और अनुरोध शुरू करता है। आप बहुत सारे टूटे हुए पाइपों के साथ समाप्त हो जाएंगे। और यह अंतिम रिलीज तक कोई समस्या नहीं थी जो देव सर्वर को पूरी तरह से अवरुद्ध कर देती है।
इसलिए, एक पूर्ण विशेषताओं वाले एप्लिकेशन सर्वर का उपयोग करने का सुझाव देना एक अच्छा समाधान है लेकिन मुझे अभी भी यहां एक समस्या दिखाई दे रही है। एक विकास केवल निश्चित रूप से समस्या है लेकिन तथ्य यह है कि ट्रिगर करना इतना आम है कि यह बहुत से डेवलपर्स के लिए परेशान करता है जो _प्रोटोकॉल आंतरिक_ के लिए उपयोग नहीं किए जाते हैं।
एक टूटा हुआ पाइप बहुत आम है (त्रुटि से एक लंबे अनुरोध के बारे में सोचें और डेवलपर ब्राउज़र स्टॉप बटन दबा रहा है) और विकास सर्वर को तोड़ना नहीं चाहिए।
एकदम मेरे विचार। :)

@xcash

यह व्यवहार आमतौर पर एक बहुत ही साधारण मामले में होता है: आप किसी प्रकार की स्वतः पूर्ण सुविधाओं का उपयोग कर रहे हैं। ब्राउज़र क्वेरी टोकन के लिए एक कनेक्शन शुरू करता है और फिर रुक जाता है और अधिक टोकन के लिए एक और अनुरोध शुरू करता है।

यदि यह संबंधित है, तो मैं पुष्टि कर सकता हूं कि मुझे browsersync साथ gulp.js का उपयोग करके इस समस्या का अनुभव हो रहा है।

क्या किसी के पास समाधान है जिसमें डब्लूएसजीआई सर्वर चलाना शामिल नहीं है? मुझे लगता है कि मेरे मेजबान के खिलाफ एक SYN स्कैन करने वाले बॉट्स के साथ इस समस्या में भाग लिया जा रहा है।

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

एफडब्ल्यूआईडब्ल्यू, मैं रिलीज के साथ ज्यादा ध्यान नहीं दे रहा हूं और यह (बहुत कष्टप्रद) समस्या मेरे लिए मई-अगस्त 2016 के बीच कुछ समय से हो रही है, सबसे अच्छा मैं बता सकता हूं। मैंने इसे अपने setup.py install_requires = ['Werkzeug<0.11', 'flask<0.11', ... जोड़ा - जो इस मुद्दे के आसपास काम करता प्रतीत होता है (IME, सिर्फ Werkzeug को पिन करना चाल नहीं लग रहा था?)

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

क्या ऐसा हो सकता है कि आप सभी ने passthrough_errors कहीं सेट किया हो?

@untitaker उस मामले में, पैलेट/फ्लास्क#1674 पैलेट/फ्लास्क#1679 पैलेट/फ्लास्क#1928 संभवतः संबंधित हैं?

मुझे नहीं पता, मैं चाहूंगा कि एक रिपोर्टर इसकी पुष्टि करे।

26 अगस्त 2016 को 17:05:25 सीईएसटी, डेविड लॉर्ड नोटिफिकेशन @github.com ने लिखा:

@untitaker उस मामले में, पैलेट/फ्लास्क#1674 पैलेट/फ्लास्क#1679
पैलेट/फ्लास्क#1928 संभवतः संबंधित हैं?

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242761250

K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

cc @miguelgrinberg

मुझे लगता है कि Werkzeug को टूटी हुई पाइप और कनेक्शन रीसेट त्रुटियों को संभालना चाहिए। ये वास्तव में किसी त्रुटि का संकेत नहीं हैं, क्लाइंट बस चला गया। ऐसा लगता है कि इस मामले में एक विशेष अपवाद उठाया जाना चाहिए, जिसे कैच-ऑल तरह से ऊपर एक के रूप में पहचाना जाता है, भले ही त्रुटि पासथ्रू सेट हो।

यहां बताया गया है कि गनिकोर्न यह कैसे करता है: https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

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

मुझे संदेह है कि यह Werkzeug में बग नहीं है, और उपयोगकर्ता का ब्राउज़र है
बस एक कनेक्शन अभी भी खुला है जो अन्य अनुरोधों को रोकता है (इसके बजाय)
सर्वर क्रैश)। यदि आप अपना ब्राउज़र बंद करते हैं और फिर से खोलते हैं, तो सर्वर को
फिर से कार्य करें।

शुक्रवार 26 अगस्त 2016 को 11:54:16 पूर्वाह्न -0700 बजे मिगुएल ग्रिनबर्ग ने लिखा:

मुझे लगता है कि Werkzeug को टूटी हुई पाइप और कनेक्शन रीसेट त्रुटियों को संभालना चाहिए। ये वास्तव में किसी त्रुटि का संकेत नहीं हैं, क्लाइंट बस चला गया। ऐसा लगता है कि इस मामले में एक विशेष अपवाद उठाया जाना चाहिए, जिसे कैच-ऑल तरह से ऊपर एक के रूप में पहचाना जाता है, भले ही त्रुटि पासथ्रू सेट हो।

यहां बताया गया है कि गनिकोर्न यह कैसे करता है: https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242821084

ओह, और टूटी हुई पाइप त्रुटियां _are_ प्रदर्शित होती हैं, हां, लेकिन उन्हें सर्वर को कभी भी वर्णित नहीं करना चाहिए। संभावित कारण के बारे में पिछली टिप्पणी देखें।

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

import time
from flask import Flask
app = Flask(__name__)


@app.route('/')
def hello_world():
    time.sleep(5)
    return 'Hello, World!'


if __name__ == "__main__":
    app.run()

यह flask run साथ अपेक्षित रूप से काम करता है लेकिन वेब सर्वर क्रैश हो जाएगा यदि आप python hello.py माध्यम से शुरू होने पर प्रतिक्रिया देने से पहले अपना वेब ब्राउज़र बंद कर देते हैं

ऐसा लगता है कि आपकी प्रतिक्रिया का एक हिस्सा खो गया है।

शुक्रवार, 26 अगस्त 2016 को दोपहर 12:29:39 अपराह्न -0700 पर, क्लेग ने लिखा:

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

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment-242829536

हां, स्लैक ट्रिपल-टिक्स में आप बोली को कैसे रोकते हैं और ctrl-return यह है कि आप कैसे नई-पंक्ति हैं
जीथब पर, ट्रिपल-टिक्स यह है कि आप उद्धरण को कैसे रोकते हैं, लेकिन ctrl-return यह है कि आप कैसे सबमिट करते हैं
... वैसे भी ... मांसपेशी स्मृति

मैंने अपनी पोस्ट को समाप्त करने के लिए सबमिट करने के तुरंत बाद संपादित किया - और मैं केवल जवाब दे रहा हूं क्योंकि ऐसा लगता है कि आप ईमेल से जवाब दे रहे हैं और मुझे यकीन नहीं है कि मेरे संपादन के बाद जीथब आपको एक और नोटिस भेजेगा।

मैं उपरोक्त @clayg द्वारा नींद परीक्षण के साथ पुन: पेश नहीं कर सकता। मुझे वास्तव में टूटी हुई पाइप त्रुटि बिल्कुल नहीं मिलती है। मैं ब्राउज़र को बंद कर देता हूं इससे पहले कि अनुरोध एक प्रतिक्रिया वापस करने के लिए हो, लेकिन Werkzeug अंत तक अनुरोध करता है वैसे भी, यह कंसोल पर 200 लॉग लाइन प्रिंट करता है और कोई त्रुटि नहीं दिखाता है।

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

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

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

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

ठीक है, मेरे विचार से जो हो रहा है उसका विश्लेषण यहां दिया गया है:

• क्लाइंट अनुरोध के बीच में चला जाता है
• अनुरोध चलता रहता है। सॉकेट कनेक्शन बफ़र किया हुआ प्रतीत होता है, इसलिए ज्यादातर मामलों में, सॉकेट को लिखने से कोई समस्या नहीं होगी।
• अनुरोध समाप्त होने के बाद, सॉकेट सर्वर वर्ग सॉकेट पर flush() जारी करेगा। यह पाइथन लाइब्रेरी में एक पुराने बग का विषय था जिसे वर्तमान में ठीक किया गया है: http://bugs.python.org/issue14574। इस फिक्स में समाधान socket.error को पकड़ना और इसे अनदेखा करना था।
• फिर सॉकेट सर्वर कनेक्शन बंद करने का प्रयास करता है। ओपी से बैकट्रैक से यह निम्न स्टैक फ्रेम है:

File "/usr/lib/python2.7/SocketServer.py", line 710, in finish self.wfile.close()

• दुर्भाग्य से, पायथन 2.7 में, पहली बात यह है कि socket.close() विधि फिर से फ्लश करती है:

File "/usr/lib/python2.7/socket.py", line 279, in close self.flush()

• फ्लश पर यह दूसरा प्रयास कोशिश/छोड़कर सुरक्षित नहीं है, इसलिए यह ईपीआईपीई अपवाद उठाता है।
• सॉकेट सर्वर अपवाद को पकड़ता है, और फिर इसे सर्वर की handle_error() विधि में वितरित करता है।
• handle_error() का Werkzeug कार्यान्वयन passthrough_errors सेटिंग को देखता है, और चूंकि हमने इसे हमेशा True सेट किया है,

पायथन 3 पर सॉकेट कोड पूरी तरह से अलग है, और विशेष रूप से, ऐसा लगता है कि उनके आस-पास कोशिश/छोड़ने के बिना कोई फ्लश कॉल नहीं है। पायथन 3 का उपयोग करते समय EPIPE त्रुटि Werkzeug तक भी बुलबुला नहीं करती है।

क्या हमारे पास भी passthrough_errors सत्य पर सेट है? Werkzeug में यह डिफ़ॉल्ट रूप से गलत है।

27 अगस्त 2016 को 02:10:13 सीईएसटी, मिगुएल ग्रिनबर्ग नोटिफिकेशन @github.com ने लिखा:

ठीक है, मेरे विचार से जो हो रहा है उसका विश्लेषण यहां दिया गया है:

• क्लाइंट अनुरोध के बीच में चला जाता है
• अनुरोध चलता रहता है। सॉकेट कनेक्शन प्रतीत होता है
  बफ़र्ड, इसलिए ज्यादातर मामलों में, सॉकेट को लिखने से कोई कारण नहीं होगा
  समस्या।
• अनुरोध समाप्त होने के बाद, सॉकेट सर्वर वर्ग flush() जारी करेगा
  सॉकेट पर। यह पायथन पुस्तकालय में एक पुराने बग का विषय था
  जो वर्तमान में ठीक है: http://bugs.python.org/issue14574। NS
  इस फिक्स में समाधान socket.error को पकड़ना और इसे अनदेखा करना था।
• फिर सॉकेट सर्वर कनेक्शन बंद करने का प्रयास करता है। यह है
  ओपी से बैकट्रैक से निम्नलिखित स्टैक फ्रेम:

 File "/usr/lib/python2.7/SocketServer.py", line 710, in finish
 self.wfile.close()

• दुर्भाग्य से, पायथन 2.7 में, पहली बात यह है कि socket.close()
  विधि फिर से फ्लश करती है:

 File "/usr/lib/python2.7/socket.py", line 279, in close
 self.flush()

• फ्लश पर यह दूसरा प्रयास कोशिश/छोड़कर सुरक्षित नहीं है, इसलिए
  यह EPIPE अपवाद उठाता है।
• सॉकेट सर्वर अपवाद को पकड़ता है, और फिर उसे वितरित करता है
  सर्वर की handle_error() विधि।
• handle_error() का Werkzeug कार्यान्वयन निम्न को देखता है
  passthrough_errors सेटिंग, और चूंकि हमने इसे हमेशा सेट किया है
  True , EPIPE त्रुटि को फिर से बढ़ाता है और इसे ऊपर तक बुलबुला बनाने देता है।

पायथन 3 पर सॉकेट कोड पूरी तरह से अलग है, और विशेष रूप से,
ऐसा लगता है कि बिना कोशिश/छोड़ के कोई फ्लश कॉल नहीं है
उन्हें। EPIPE त्रुटि का उपयोग करते समय Werkzeug तक बुलबुला भी नहीं होता है
पायथन 3.

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242881523

K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

ओह, अहम: https://github.com/pallets/flask/pull/1679

मुझे लगता है कि passthrough_errors app.debug पर निर्भर होना चाहिए। एनवीएम, बेकार है

मुझे वास्तव में उस पीआर को वापस करने के अलावा कोई विकल्प नहीं दिखता। passthrough_errors=True बस वही करता है जो उसे करना चाहिए, जो एक अच्छा डिफ़ॉल्ट व्यवहार नहीं है यदि किसी ने प्रोग्राम में डीबगर संलग्न नहीं किया है।

कोई बात नहीं, मुझे दूसरा रास्ता मिल गया। दो जनसंपर्क:

• https://github.com/pallets/flask/pull/1996 - यह समस्या को अपने आप ठीक कर देगा, सिवाय इसके कि ट्रेसबैक अभी भी दिखाई दे रहा है
• https://github.com/pallets/werkzeug/pull/998 -- भले ही passthrough_errors=True , सॉकेट त्रुटियों को कभी भी दोबारा न करें। मुझे नहीं लगता कि वैसे भी कभी इरादा था

चूंकि दोनों व्यापक अर्थों में व्यवहार परिवर्तन हैं, इसलिए मैं उन्हें बैकपोर्ट नहीं करना चाहूंगा।

मुझे लगता है कि https://github.com/pallets/flask/pull/1996 एक स्वीकार्य समाधान है। महत्वपूर्ण बात यह है कि यह उस सामान्य मामले को ठीक करता है जहां आप अपवादों को प्रचारित नहीं करना चाहते हैं। यदि आप प्रचार करना चाहते हैं, तो आप डिबगिंग कर रहे हैं, और उस स्थिति में सॉकेट प्राप्त करना। त्रुटि को प्रचारित किया जाना चाहिए जब यह एक बड़ा सौदा नहीं है।

हालांकि https://github.com/pallets/werkzeug/pull/998 फिक्स बहुत अच्छा नहीं है। एप्लिकेशन इन अपवादों को वैध रूप से अपने स्वयं के हैंडलर में सॉकेट के साथ कर रहा है, और उन्हें भी चुप करा दिया जाएगा। आदर्श समाधान यह होगा कि ये उस स्थान पर पकड़े जाते हैं जहां वे होते हैं और फिर कुछ कस्टम अपवाद वर्ग के रूप में फिर से उठाए जाते हैं जिन्हें handle_error पहचान और अनदेखा कर सकता है। यह देखते हुए कि हम शायद SocketServer को बदलना या अधिभारित नहीं करना चाहते हैं, मुझे लगता है कि मेरा वोट इस हिस्से को वैसे ही छोड़ना है। आप ईपीआईपीई को कंसोल पर डंप कर देंगे, लेकिन केवल पायथन 2 पर, और कम से कम यह सर्वर को अन्य फिक्स के बाद बंद नहीं करेगा। यह हानिरहित है, और यह एक ऐसा व्यवहार है जो अतीत में मौजूद था, इससे पहले कि मैंने इसे बनाया passthrough_errors परिवर्तन।

आपके द्वारा वर्णित व्यवहार केवल PASSTHROUGH_ERRORS सक्षम होने पर ही होता है। अन्यथा फ्लास्क के भीतर से अपवाद पकड़ा जाता है।

मुझे लगता है कि यह कॉस्मेटिक सुधार इसके लायक नहीं है।

27 अगस्त 2016 को 18:29:30 सीईएसटी, मिगुएल ग्रिनबर्ग नोटिफिकेशन @github.com ने लिखा:

मुझे लगता है कि https://github.com/pallets/flask/pull/1996 स्वीकार्य है
समाधान। महत्वपूर्ण बात यह है कि यह सामान्य मामले को ठीक करता है जहां
आप अपवादों को प्रचारित नहीं करना चाहते हैं। यदि आप प्रचार करना चाहते हैं,
तो आप डिबगिंग कर रहे हैं, और उस स्थिति में सॉकेट प्राप्त कर रहे हैं
प्रचारित जब यह नहीं होना चाहिए तो यह बहुत बड़ी बात नहीं है।

https://github.com/pallets/werkzeug/pull/998 फिक्स बढ़िया नहीं है
हालांकि। आवेदन इन अपवादों को वैध रूप से उठा सकता है
कुछ यह अपने स्वयं के हैंडलर में सॉकेट के साथ कर रहा है, और वे करेंगे
खामोश भी हो। आदर्श समाधान यह होगा कि ये पकड़े जाएं
उस स्थान पर जहां वे होते हैं और फिर कुछ कस्टम अपवाद के रूप में फिर से उठाए जाते हैं
वर्ग जिसे handle_error पहचान और अनदेखा कर सकता है। यह देखते हुए कि हम
शायद SocketServer को बदलना या अधिभारित नहीं करना चाहता, मुझे लगता है कि my
वोट इस हिस्से को ऐसे ही छोड़ देना है। आपको EPIPE को डंप कर दिया जाएगा
कंसोल, लेकिन केवल पायथन 2 पर, और कम से कम यह रुकने वाला नहीं है
अन्य सुधार के बाद सर्वर अंदर चला जाता है। यह हानिरहित है, और यह एक है
व्यवहार जो अतीत में मौजूद था, मेरे द्वारा किए जाने से पहले
passthrough_errors परिवर्तन।

आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242926832

K-9 मेल के साथ मेरे Android डिवाइस से भेजा गया। मेरे संक्षिप्तता को माफ़ करो।

मास्टर में फिक्स्ड।

आपके द्वारा वर्णित व्यवहार केवल PASSTHROUGH_ERRORS सक्षम होने पर ही होता है

हां, मैंने वह विवरण छोड़ दिया है। लेकिन यह परिवर्तन Python 3 को भी प्रभावित करेगा, जहाँ इनमें से कोई भी समस्या नहीं है। Py3 पर, पासथ्रू त्रुटियों को सक्षम करने के साथ, एक वैध सॉकेट। एप्लिकेशन द्वारा उठाए गए त्रुटि को चुप करा दिया जाएगा।

मास्टर wfm लगता है, अगली रिलीज की प्रतीक्षा कर रहा है, धन्यवाद!

नमस्ते, मैं एनजीआईएनएक्स के पीछे चल रहे एक वेर्कज़ेग देव सर्वर का उपयोग करता हूं, मुझे एक ही समस्या का सामना करना पड़ रहा है, क्या कोई मेरी मदद कर सकता है,
11:13:11 web.1 | 127.0.0.1 - - [15/Sep/2016 11:13:11] "GET /api/method/frappe.utils.print_format.download_pdf?doctype=Purchase%20Order&name=PO-00001&format=PO&no_letterhead=0 HTTP/1.1" 200 - 11:13:11 web.1 | Error on request: 11:13:11 web.1 | Traceback (most recent call last): 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 193, in run_wsgi 11:13:11 web.1 | execute(self.server.app) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 184, in execute 11:13:11 web.1 | write(data) 11:13:11 web.1 | File "/home/ommi/frappe-bench/env/lib/python2.7/site-packages/werkzeug/serving.py", line 152, in write 11:13:11 web.1 | self.send_header(key, value) 11:13:11 web.1 | File "/usr/lib/python2.7/BaseHTTPServer.py", line 401, in send_header 11:13:11 web.1 | self.wfile.write("%s: %s\r\n" % (keyword, value)) 11:13:11 web.1 | IOError: [Errno 32] Broken pipe

कृपया सहायता कीजिए

राघव वर्कज़ेग के बिल्ट इन देव के बजाय किसी अन्य एप्लिकेशन सर्वर का उपयोग करते हैं
सर्वर, गनिकोर्न की तरह। अभी यही एकमात्र उपाय है।

2016-09-15 8:07 जीएमटी+02:00 रागव सूचनाएं @github.com :

नमस्ते, मैं NGINX के पीछे चल रहे एक Werkzeug dev सर्वर का उपयोग करता हूं, मैं इसका सामना कर रहा हूं
वही समस्या क्या कोई मेरी मदद कर सकता है, ```
11:13:11 वेब.1 | 127.0.0.1 - - [15/सितंबर/2016 11:13:11] "प्राप्त करें"
/api/method/frappe.utils.print_format.download_pdf?
doctype=Purchase%20Order&name=PO-00001&format=PO&no_letterhead=0
एचटीटीपी/1.1" 200 -
11:13:11 वेब.1 | अनुरोध पर त्रुटि:
11:13:11 वेब.1 | ट्रेसबैक (सबसे हालिया कॉल अंतिम):
11:13:11 वेब.1 | फ़ाइल "/ होम/ओमी/फ्रेपे-बेंच/एनवी/
lib/python2.7/site-packages/werkzeug/serving.py", पंक्ति 193, run_wsgi में
11:13:11 वेब.1 | निष्पादित करें (self.server.app)
11:13:11 वेब.1 | फ़ाइल "/ होम/ओमी/फ्रेपे-बेंच/एनवी/
lib/python2.7/site-packages/werkzeug/serving.py", पंक्ति 184, निष्पादन में
11:13:11 वेब.1 | लिखना (डेटा)
11:13:11 वेब.1 | फ़ाइल "/ होम/ओमी/फ्रेपे-बेंच/एनवी/
lib/python2.7/site-packages/werkzeug/serving.py", पंक्ति 152, लिखित में
11:13:11 वेब.1 | self.send_header (कुंजी, मान)
11:13:11 वेब.1 | फ़ाइल "/usr/lib/python2.7/BaseHTTPServer.py", लाइन 401,
send_header . में
11:13:11 वेब.1 | self.wfile.write("%s: %s\r\n" % (कीवर्ड, मान))
11:13:11 वेब.1 | IOError: [Errno 32] टूटा हुआ पाइप

कृपया सहायता कीजिए

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/pallets/werkzeug/issues/954#issuecomment -247243400,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AA6MZ6DNiRIfL91CLeYOoA70W9_nQQzGks5qqOCMgaJpZM4I58cy
.

हालिया फिक्स कमिट द्वारा निर्देशित, मैं app.run को passthrough_errors=False के साथ कॉल करके इस समस्या को ठीक करने में सक्षम हूं। वाईएमएमवी

क्रैश का कारण बनने वाले बग को 21 दिसंबर 2016 को जारी

• एक आंतरिक सर्वर त्रुटि (पुल अनुरोध # 2006) को वापस करने के बजाय देव सर्वर को क्रैश करने वाले व्यवहार परिवर्तन को वापस लाएं।

संस्करण 0.12 केवल पिछले सप्ताह जारी किया गया है।

सोम, 20 मार्च, 2017 को 09:05:00 पूर्वाह्न -0700 बजे, एलन रोटमैन ने लिखा:

क्रैश का कारण बनने वाले बग को 21 दिसंबर 2016 को जारी

• एक आंतरिक सर्वर त्रुटि (पुल अनुरोध # 2006) को वापस करने के बजाय देव सर्वर को क्रैश करने वाले व्यवहार परिवर्तन को वापस लाएं।

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपने खुली/बंद स्थिति को संशोधित किया है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287807602

मैंने आज ही रिलीजनोट्स देखे हैं, और इस सुधार का लंबे समय से इंतजार कर रहा हूं।

देखें: http://flask.pocoo.org/docs/0.12/changelog/
संस्करण 0.12
21 दिसंबर 2016 को जारी, कोडनेम Punsch।

https://pypi.python.org/pypi/Flask/0.12
फ़ाइल प्रकार Py संस्करण आकार पर अपलोड किया गया
कुप्पी-0.12-py2.py3-none-any.whl (md5) पायथन व्हील 2.7 2016-12-21 80KB
कुप्पी-0.12.tar.gz (md5) स्रोत 2016-12-21 519KB

आह, हाँ, आपका मतलब फ्लास्क है। ज़रूर।

सोम, 20 मार्च, 2017 को 09:22:15 पूर्वाह्न -0700 पर, एलन रोटमैन ने लिखा:

मैंने आज ही रिलीजनोट्स देखे हैं, और इस सुधार का लंबे समय से इंतजार कर रहा हूं।

देखें: http://flask.pocoo.org/docs/0.12/changelog/
संस्करण 0.12
21 दिसंबर 2016 को जारी, कोडनेम Punsch।

https://pypi.python.org/pypi/Flask/0.12
फ़ाइल प्रकार Py संस्करण आकार पर अपलोड किया गया
कुप्पी-0.12-py2.py3-none-any.whl (md5) पायथन व्हील 2.7 2016-12-21 80KB
कुप्पी-0.12.tar.gz (md5) स्रोत 2016-12-21 519KB

--
आप इसे प्राप्त कर रहे हैं क्योंकि आपने खुली/बंद स्थिति को संशोधित किया है।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287813405

थ्रेडेड = ट्रू मोड में वर्कज़ेग पर फ्लास्क 0.12.2 चलाते समय इस मुद्दे पर चलने वाले किसी भी व्यक्ति के लिए बस एक नोट:
थ्रेडेड मोड में, डिफ़ॉल्ट रूप से ऐसा लगता है कि प्रत्येक वर्कज़ेग थ्रेड में वास्तव में अभी भी यह समस्या है, अर्थात यदि आप किसी ऐसे मार्ग का अनुरोध करते हैं जो वापस आने में कुछ समय लेता है, और फिर क्लाइंट से कनेक्शन बंद कर देता है, तो वह विशेष रूप से Werkzeug एक IOError ब्रोकन पाइप लॉग करता है और फिर मर जाता है। सर्वर समग्र रूप से कार्य करना जारी रखता है, सिवाय इसके कि मेरे आवेदन में मुझे पता चल रहा था कि यह किसी भी तरह से स्मृति रिसाव पैदा कर रहा था, किसी भी धागे में टूटे पाइप के बाद फ्लास्क प्रक्रिया धीरे-धीरे बढ़ रही थी, सभी रैम का उपयोग करके और फिर स्वैप और अंत में जा रहा था ओएस द्वारा मारे गए।
स्पष्ट रूप से passthrough_errors=False in app.run भेजने से लगता है कि समस्या का समाधान हो गया है - क्लाइंट के डिस्कनेक्ट होने पर थ्रेड्स अब नहीं मरते हैं, वे इनायत से IOError को लॉग करते हैं और फिर इसे लॉग भी करते हैं (जिसे मैंने कभी भी पासथ्रू_एरर्स = गलत सेट किए बिना नहीं देखा):

Exception happened during processing of request from ('127.0.0.1', 50652)
----------------------------------------

और फिर सर्वर सामान्य रूप से चलता रहता है। मुझे अभी भी यह देखने के लिए कुछ घंटों का इंतजार करना है कि क्या स्मृति रिसाव फिर से दिखाई देता है, लेकिन मुझे उम्मीद है कि ऐसा नहीं होगा।

बस अगर यह किसी के लिए मददगार है।

मैंने यह त्रुटि उबंटू वीएम पर कुबेरनेट्स पर उबंटू डॉकर कंटेनर में भी देखी:

Error on request:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 270, in run_wsgi
    execute(self.server.app)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 261, in execute
    write(data)
  File "/usr/local/lib/python2.7/dist-packages/werkzeug/serving.py", line 227, in write
    self.send_header(key, value)
  File "/usr/lib/python2.7/BaseHTTPServer.py", line 412, in send_header
    self.wfile.write("%s: %s\r\n" % (keyword, value))
IOError: [Errno 32] Broken pipe

मैंने एक बिल्कुल नया Ubuntu xenial VM बनाया और Kubernetes पर Ubuntu Docker कंटेनर में समान कोड चलाया, और यह त्रुटि नहीं देखी गई और Python Flask ने अपेक्षा के अनुरूप काम किया। मुझे लगता है कि यह मेरे मेजबान (उबंटू वीएम) के साथ मुद्दा था।

@vhosakot क्या आप मुझे

रूट फ़ंक्शन में, मैंने एक अन्य फ़ंक्शन का उपयोग किया जो रूटिंग के लिए था।
मैंने उस फ़ंक्शन की प्रतिक्रिया से डेटा प्राप्त किया।
अब, जब मैंने उस डेटा पर _loads()_ का उपयोग किया, तो मुझे त्रुटि मिल रही है।

...
response = get_contents().data
        if response:
            data = loads(response)
..

त्रुटि: IOError: [Errno 32] Broken pipe