Werkzeug: يتعطل 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

أواجه نفس المشكلة مثل sfermigier مع خادم التطوير ( debug=True ) ، ولدي نفس الخطأ في التتبع.

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

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

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

إذا كانت مرتبطة ، يمكنني أن أؤكد أنني واجهت هذه المشكلة باستخدام browsersync مع gulp.js .

هل لدى أي شخص حل لا يتضمن تشغيل خادم WSGI؟ يبدو أنني أواجه هذه المشكلة مع قيام الروبوتات بإجراء فحص SYN ضد مضيفي.

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

FWIW ، لم أواكب الإصدارات كثيرًا وبدأت هذه المشكلة (المزعجة جدًا) تحدث لي في وقت ما بين مايو وأغسطس 2016 أفضل ما يمكنني قوله. لقد أضفت هذا إلى setup.py install_requires = ['Werkzeug<0.11', 'flask<0.11', ... - والذي يبدو أنه يعمل على حل المشكلة (يبدو أن تثبيت Werkzeug لم يفلح في حل المشكلة؟)

بالنسبة لي ، كانت حالة النسخ بسيطة بما يكفي - قم بتحميل صفحة ، لكن لا تدعها تنتهي من التحميل. أي ، ما عليك سوى تشغيل _any_ خطأ الأنبوب المعطل - وسوف يتعطل خادم الويب ويفشل في خدمة أي طلبات أخرى. IMHO ، لا يمكن لخوادم الويب أن تتسرب عندما يغلق العميل الاتصال قبل الأوان - حتى تلك المطورة.

هل يمكن أن يكون لديك جميعًا passthrough_errors تعيينه في مكان ما؟

untitaker في هذه الحالة ، المنصات / القارورة # 1674 pallets / flask # 1679 pallets / flask # 1928 ربما ذات صلة؟

لا أعرف ، أود أن يؤكد أحد المراسلين.

في 26 أغسطس 2016 ، الساعة 17:05:25 بتوقيت وسط أوروبا الصيفي ، كتب David Lord [email protected] :

untitaker في هذه الحالة ، المنصات / القارورة # 1674 pallets / flask # 1679
المنصات / القارورة # 1928 ربما ذات صلة؟

أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242761250

مُرسَل من جهازي الذي يعمل بنظام Android مع K-9 Mail. عذرا على الاختصار.

ccmiguelgrinberg

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

إليك كيفية قيام Gunicorn بذلك: https://github.com/benoitc/gunicorn/blob/39f62ac66beaf83ceccefbfabd5e3af7735d2aff/gunicorn/workers/sync.py#L151 -L154

هذا ما يفترض أن تفعله. أحاول معرفة كيفية التكاثر
هذا السلوك ، ولكن لا يوجد اختبار واضح متاح حتى الآن. ومن هنا السؤال
حول passthrough_errors .

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

في الجمعة ، 26 أغسطس ، 2016 الساعة 11:54:16 صباحًا -0700 ، كتب ميغيل جرينبيرج:

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

إليك كيفية قيام Gunicorn بذلك: 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

نعم ، في Slack Triple-Ticks هي كيفية منع عرض الأسعار و ctrl-return هي الطريقة الجديدة
على github ، العلامات الثلاثية هي كيفية منع عرض الأسعار ، ولكن ctrl-return هي الطريقة التي ترسل بها
... على أي حال ... ذاكرة العضلات

لقد قمت بتحرير رسالتي على الفور بعد إرسالها للانتهاء - وأنا أرد فقط لأنه يبدو أنك ترد من البريد الإلكتروني ولست متأكدًا من أن github سيرسل إليك إشعارًا آخر بعد تعديلي.

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

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

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

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

تحرير: تجاهل أداة إعادة التحميل التي تبدأ جزء عملية آخر ، لا يبدو أن هذا يحدث ، وبدلاً من ذلك كنت أرى على الأرجح تأثير تغيير إعداد خطأ العبور.

حسنًا ، إليك تحليل ما أعتقد أنه يحدث:

• يذهب العميل في منتصف الطلب
• الطلب يستمر. يبدو أن اتصال المقبس تم تخزينه مؤقتًا ، لذلك في معظم الحالات ، لن تتسبب عمليات الكتابة على المقبس في أي مشاكل.
• بمجرد انتهاء الطلب ، ستصدر فئة خادم المقبس flush() على المقبس. كان هذا موضوع خطأ قديم في مكتبة Python تم إصلاحه حاليًا: http://bugs.python.org/issue14574. كان الحل في هذا الإصلاح هو التقاط socket.error وتجاهله.
• ثم يحاول خادم مأخذ التوصيل إغلاق الاتصال. هذا هو إطار المكدس التالي ، من backtrace من OP:

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

• لسوء الحظ ، في Python 2.7 ، أول شيء تفعله طريقة socket.close() هو التدفق مرة أخرى:

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

• هذه المحاولة الثانية في التدفق غير محمية بمحاولة / باستثناء ، لذلك فإنها تثير استثناء EPIPE.
• يلتقط خادم المقبس الاستثناء ، ثم يسلمه إلى طريقة handle_error() للخادم.
• ينظر تطبيق Werkzeug لـ handle_error() إلى الإعداد passthrough_errors ، وبما أننا قمنا دائمًا بتعيين هذا على True ، فإنه يعيد رفع خطأ EPIPE ويسمح له بالظهور إلى أعلى.

رمز المقبس في Python 3 مختلف تمامًا ، وعلى وجه الخصوص ، لا يبدو أنه يحتوي على أي مكالمات دون محاولة / استثناءات من حولهم. خطأ EPIPE لا يصل حتى إلى Werkzeug عند استخدام Python 3.

هل لدينا حتى أخطاء في المرور مضبوطة على "صواب"؟ في Werkzeug هو خطأ افتراضيًا.

في 27 أغسطس 2016 02:10:13 CEST ميغيل غرينبرغ [email protected] كتب:

حسنًا ، إليك تحليل ما أعتقد أنه يحدث:

• يذهب العميل في منتصف الطلب
• الطلب يستمر. يبدو أن اتصال المقبس
  مخزنة ، لذلك في معظم الحالات ، لن تتسبب عمليات الكتابة على المقبس في أي شيء
  مشاكل.
• بمجرد انتهاء الطلب ، ستصدر فئة خادم المقبس flush()
  على المقبس. كان هذا موضوع خطأ قديم في مكتبة بايثون
  تم إصلاحه حاليًا: http://bugs.python.org/issue14574. ال
  كان الحل في هذا الإصلاح هو التقاط socket.error وتجاهله.
• ثم يحاول خادم مأخذ التوصيل إغلاق الاتصال. هذا ال
  إطار المكدس التالي ، من backtrace من OP:

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

• لسوء الحظ ، في Python 2.7 ، أول شيء socket.close()
  الطريقة هل هي دافق مرة أخرى:

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

• هذه المحاولة الثانية في التدفق غير محمية بمحاولة / باستثناء ، لذلك
  يقوم بإصدار استثناء EPIPE.
• يلتقط خادم مأخذ التوصيل الاستثناء ، ثم يسلمه إلى ملف
  طريقة handle_error() للخادم.
• يبدو تطبيق Werkzeug لـ handle_error() في ملف
  passthrough_errors ، ونظرًا لتعيين هذا دائمًا على
  True ، يعيد رفع خطأ EPIPE ويتيح له الظهور إلى الأعلى.

رمز المقبس في Python 3 مختلف تمامًا ، وعلى وجه الخصوص ،
لا يبدو أنه يحتوي على أي مكالمات دون محاولة / استثناءات
معهم. خطأ EPIPE لا يصل حتى إلى Werkzeug عند استخدام
بايثون 3.

أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242881523

مُرسَل من جهازي الذي يعمل بنظام Android مع K-9 Mail. عذرا على الاختصار.

أوه ، مهم: https://github.com/pallets/flask/pull/1679

أعتقد أن passthrough_errors يجب أن يعتمد على app.debug . NVM ، غير مجدية

لا أرى أي خيار سوى إعادة تلك العلاقات العامة في الواقع. 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 ، أعتقد أن تصويتي هو ترك هذا الجزء كما هو. ستحصل على EPIPE ملقاة في وحدة التحكم ، ولكن فقط في Python 2 ، وعلى الأقل لن يوقف الخادم بعد إدخال الإصلاح الآخر. إنه غير ضار ، وهو سلوك كان موجودًا في الماضي ، قبل أن أقوم بعمل passthrough_errors .

السلوك الذي تصفه يحدث فقط مع تمكين PASSTHROUGH_ERRORS. خلاف ذلك ، يتم اكتشاف الاستثناء من داخل Flask.

أعتقد أن هذا التحسين التجميلي لا يستحق ذلك بالرغم من ذلك.

في 27 أغسطس 2016 18:29:30 CEST ميغيل غرينبرغ [email protected] كتب:

أعتقد أن https://github.com/pallets/flask/pull/1996 مقبول
المحلول. الشيء المهم هو أنه يصلح الحالة المشتركة حيث
لا تريد نشر الاستثناءات. إذا كنت تريد التكاثر ،
فأنت تقوم بالتصحيح ، وفي هذه الحالة تحصل على خطأ في المقبس
تنتشر عندما لا تكون صفقة ضخمة.

إصلاح https://github.com/pallets/werkzeug/pull/998 ليس رائعًا
على أية حال. قد يثير التطبيق هذه الاستثناءات بشكل شرعي من
شيء تفعله مع مآخذ في معالجاتها الخاصة ، وهؤلاء سيفعلون
يتم إسكاته أيضًا. الحل المثالي هو أن يتم الإمساك بها
في المكان الذي تحدث فيه ثم أعيد ظهوره كإحدى الاستثناءات المخصصة
فئة يستطيع handle_error التعرف عليها وتجاهلها. بالنظر إلى أننا
ربما لا تريد تغيير أو زيادة التحميل على SocketServer ، على ما أعتقد
التصويت هو مجرد ترك هذا الجزء كما هو. سوف تحصل على EPIPE ملقاة إلى
وحدة التحكم ، ولكن فقط في Python 2 ، وعلى الأقل لن تتوقف
الخادم بعد إدخال الإصلاح الآخر. إنه غير ضار ، وهو ملف
الذي كان موجودًا في الماضي ، قبل أن أقوم بعمل
passthrough_errors .

أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -242926832

مُرسَل من جهازي الذي يعمل بنظام Android مع K-9 Mail. عذرا على الاختصار.

ثابت في الماجستير.

السلوك الذي تصفه يحدث فقط مع تمكين PASSTHROUGH_ERRORS

نعم ، لقد حذفت هذه التفاصيل. لكن هذا التغيير سيؤثر حتى على Python 3 ، حيث لا يمثل أي من هذا مشكلة. في Py3 ، مع تمكين أخطاء المرور ، سيتم إسكات خطأ socket.ar شرعي أثاره التطبيق.

يبدو أن السيد wfm ، يتطلع إلى الإصدار التالي ، شكرًا!

مرحبًا ، أستخدم خادم مطور Werkzeug يعمل خلف NGINX ، أواجه نفس المشكلة هل يمكن لأي شخص مساعدتي في ذلك ،
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

الرجاء المساعدة

يستخدم Ragav خادم تطبيق آخر بدلاً من خادم werkzeug المدمج في dev
الخادم ، مثل gunicorn. إنه الحل الوحيد الآن.

2016-09-15 8:07 بتوقيت جرينتش + 02: 00 Ragav [email protected] :

مرحبًا ، أستخدم خادم Werkzeug dev يعمل خلف NGINX ، وأواجه ملف
نفس المشكلة يمكن لأي شخص أن يساعدني في هذا ، ''
11:13:11 شبكة 1 | 127.0.0.1 - [15 / سبتمبر / 2016 11:13:11] "GET
/api/method/frappe.utils.print_format.download_pdf؟
Dictype = شراء٪ 20Order & name = PO-00001 & format = PO & no_letterhead = 0
HTTP / 1.1 "200 -
11:13:11 شبكة 1 | خطأ عند الطلب:
11:13:11 شبكة 1 | Traceback (آخر مكالمة أخيرة):
11:13:11 شبكة 1 | ملف "/ home / ommi / frappe-bench / env /
lib / python2.7 / site -pack / werkzeug / serve.py "، السطر 193 ، في run_wsgi
11:13:11 شبكة 1 | تنفيذ (self.server.app)
11:13:11 شبكة 1 | ملف "/ home / ommi / frappe-bench / env /
lib / python2.7 / site -pack / werkzeug / serve.py "، السطر 184 ، قيد التنفيذ
11:13:11 شبكة 1 | الكتابة (البيانات)
11:13:11 شبكة 1 | ملف "/ home / ommi / frappe-bench / env /
lib / python2.7 / site -pack / werkzeug / serve.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 | خطأ IO: [Errno 32] أنبوب مكسور

الرجاء المساعدة

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/pallets/werkzeug/issues/954#issuecomment -247243400 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AA6MZ6DNiRIfL91CLeYOoA70W9_nQQzGks5qqOCMgaJpZM4I58cy
.

مسترشدًا بإصلاح الإصلاح الأخير ، تمكنت من حل هذه المشكلة عن طريق الاتصال بـ app.run with passthrough_errors = False. YMMV

تم إصلاح الخطأ الذي تسبب في التعطل

• التراجع عن تغيير السلوك الذي أدى إلى تعطل خادم dev بدلاً من إرجاع خطأ خادم داخلي (طلب السحب رقم 2006).

تم إصدار الإصدار 0.12 الأسبوع الماضي فقط.

في يوم الإثنين 20 مارس 2017 الساعة 09:05:00 صباحًا -0700 ، كتب آلان روتمان:

تم إصلاح الخطأ الذي تسبب في التعطل

• التراجع عن تغيير السلوك الذي أدى إلى تعطل خادم dev بدلاً من إرجاع خطأ خادم داخلي (طلب السحب رقم 2006).

-
أنت تتلقى هذا لأنك قمت بتعديل حالة الفتح / الإغلاق.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287807602

لقد رأيت للتو ReleaseNotes اليوم ، وكنت أنتظر هذا الإصلاح لفترة طويلة.

انظر إلى: http://flask.pocoo.org/docs/0.12/changelog/
الإصدار 0.12.0
صدر في 21 ديسمبر 2016 ، الاسم الرمزي Punsch.

https://pypi.python.org/pypi/Flask/0.12
نوع الملف Py الإصدار تم تحميله على الحجم
Flask-0.12-py2.py3-none-any.whl (md5) Python Wheel 2.7 2016-12-21 80KB
Flask-0.12.tar.gz (md5) المصدر 2016-12-21 519KB

آه ، نعم ، تقصد قارورة. بالتأكيد.

في يوم الإثنين 20 مارس 2017 الساعة 09:22:15 صباحًا -0700 صباحًا ، كتب آلان روتمان:

لقد رأيت للتو ReleaseNotes اليوم ، وكنت أنتظر هذا الإصلاح لفترة طويلة.

انظر إلى: http://flask.pocoo.org/docs/0.12/changelog/
الإصدار 0.12.0
صدر في 21 ديسمبر 2016 ، الاسم الرمزي Punsch.

https://pypi.python.org/pypi/Flask/0.12
نوع الملف Py الإصدار تم تحميله على الحجم
Flask-0.12-py2.py3-none-any.whl (md5) Python Wheel 2.7 2016-12-21 80KB
Flask-0.12.tar.gz (md5) المصدر 2016-12-21 519KB

-
أنت تتلقى هذا لأنك قمت بتعديل حالة الفتح / الإغلاق.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/pallets/werkzeug/issues/954#issuecomment -287813405

مجرد ملاحظة لأي شخص يواجه هذه المشكلة عند تشغيل القارورة 0.12.2 في werkzeug في الخيوط = الوضع الصحيح:
في الوضع المترابط ، يبدو أن كل مؤشر ترابط werkzeug لا يزال يواجه هذه المشكلة بالفعل ، أي إذا طلبت مسارًا يستغرق بعض الوقت للعودة ، ثم أغلقت الاتصال من العميل ، فإن هذا werkzeug المحدد يسجل خطأ IOError Broken Pipe ثم يموت. يستمر الخادم بشكل عام في العمل ، باستثناء أنه في تطبيقي كنت أجد أن هذا يتسبب في حدوث تسرب للذاكرة بطريقة ما ، مع نمو عملية القارورة ببطء بعد أنبوب مكسور في أي مؤشر ترابط ، باستخدام كل ذاكرة الوصول العشوائي (RAM) ثم SWAP ثم يتم أخيرًا قتل من قبل نظام التشغيل.
إرسال passthrough_errors = False in app.run يبدو أنه حل المشكلة - لم تعد سلاسل الرسائل تموت عند قطع اتصال العميل ، بل قاموا بتسجيل خطأ IOError بأمان ثم تسجيل ذلك أيضًا (وهو ما لم أره مطلقًا بدون تعيين passthrough_errors = False):

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

ثم يستمر الخادم في العمل كالمعتاد. لا يزال يتعين علي الانتظار بضع ساعات لمعرفة ما إذا كان تسرب الذاكرة سيظهر مرة أخرى ، لكنني آمل ألا يحدث ذلك.

فقط في حال كان ذلك مفيدًا لأي شخص.

لقد رأيت هذا الخطأ أيضًا في حاوية Ubuntu Docker على Kubernetes على Ubuntu VM:

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 جديد تمامًا وقمت بتشغيل نفس الكود في حاوية Ubuntu Docker على Kubernetes ، ولم يتم رؤية هذا الخطأ وعمل Python Flask كما هو متوقع. أعتقد أنه كان مشكلة مع مضيفي (Ubuntu VM).

vhosakot هل يمكنك إخباري بكيفية إعداد تكوين التطبيق الخاص بك؟ لقد واجهت مشكلة مماثلة في نفس بيئة مشكلتك.

في وظيفة المسار ، استخدمت وظيفة أخرى كانت مخصصة للتوجيه.
لقد جلبت البيانات من استجابة تلك الوظيفة.
الآن ، عندما استخدمت _loads () _ على تلك البيانات ، أتلقى الخطأ.

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

الخطأ: IOError: [Errno 32] Broken pipe