<p>werkzeug.serving.run_simple لا يعالج SIGTERM بشكل صحيح</p>

تم إنشاؤها على ٩ مايو ٢٠١١  ·  11تعليقات  ·  مصدر: pallets/werkzeug

عندما تتلقى العملية SIGTERM ، يجب أن تغلق وتخرج ، مع أقل عدد ممكن من العمليات وبدون طباعة أي شيء.

ينتج عن عملية werkzeug.serving.run_simple تستقبل SIGTERM عمومًا رمز إرجاع يبلغ 141 (أحد أعراض عدم التعامل مع SIGPIPE ) ، وعند استخدام أداة إعادة التحميل ، تتحول العملية إلى زومبي (لقد ليتم قتلها يدويًا ، حيث يظل المنفذ مقيدًا).

تعد إضافة معالج إشارة مقابل SIGTERM والذي يستدعي ببساطة sys.exit(0) كافياً لإصلاح المشكلة (حيث لم يعد هناك سلوك خاطئ للعملية) ، لكنني لست متأكدًا من أنه الإصلاح الصحيح بالفعل.

bug

التعليق الأكثر فائدة

لقد تعرضت لهذا الخطأ أيضًا ، في حالتي ، كان docker stop يرسل SIGTERM إلى خادم يعمل بنظام werkzeug (moto) ، ولكن تم تجاهل الخادم ثم قتل عامل الرصيف بـ SIGKILL نتيجة إلى رمز خروج غير صفري.

كان الحل هو تحديد SIGINT (Ctrl + C) كإشارة توقف مفضلة في Dockerfile ( STOPSIGNAL SIGINT ) ، بعد ذلك يتم إغلاق الحاويات بشكل نظيف.

ال 11 كومينتر

أقوم بربط معالج إشارة الآن عند التشغيل باستخدام أداة إعادة التحميل. امل ان يساعد.

في أي إصدار يتم هذا الإصلاح؟ لا تزال هذه مشكلة في Flask 0.8.

لا تزال هذه مشكلة ، إنها مزعجة للغاية عند استخدام Flask مع IDE - كلما توقفت عن تصحيح الأخطاء ، تستمر العملية وتستمر في خدمة الطلبات.

أنا أعيد فتح هذه المشكلة لأنها تبدو مستمرة ، راجع المناقشة التالية من IRC اليوم.

20:20 < mcdonc> can somebody fix flask's reloader so when you send the process a sigint it actually stops the child process
20:20 < untitaker> mcdonc: it seems to work for me
20:21 < untitaker> mcdonc: it used to cause problems but for me it's fixed in latest master
20:21 < mcdonc> ah good.  i just got some number of complaints from people who run it under supervisor.
20:22 < untitaker> mcdonc: you are talking about the one from the Py3 port?
20:22 < untitaker> released versions should work properly
20:22 < mcdonc> no.. i am talking about.. well.. yes, i dont actually know what i'm talking about ;-)  i dont use it, i just get people telling me they need to send a stop signal to the entire process group instead of to the process to make sure its killed.
20:23 < mcdonc> this is not recent.. for the last year or so
20:23 < mcdonc> why people run the reloader under supervisor (presumably in production) i cannot fathom
20:23 < mcdonc> but they do
20:24 < Alex_Gaynor> mcdonc: I've toyed with using supervisord in dev, FWIW
20:24 < Alex_Gaynor> mcdonc: for cases where you don't just have web proc, you've also got background daemons and such, it could be nice
[...]
20:32 < DasIch> untitaker: the supervisor issue is independent from the threading/thread issue
20:32 < untitaker> DasIch: ah okay
20:32 < untitaker> didn't know that
20:32 < untitaker> DasIch: is the reloader behaving weird in supervisor?
20:33 < DasIch> untitaker: I guess what happens if you run the reloader in supervisor is that supervisor kill the reloading process but that doesn't kill the process started by the reloader
20:34 < untitaker> DasIch: couldn't one write a wrapper shell script that kills both?
20:34 < untitaker> at least for now
20:34 < DasIch> untitaker: I think you shouldn't use the reloader in production
20:35 < untitaker> well yeah
20:35 < asdf`> (supervisord has a 'kill as group' thing)
20:35 < DasIch> right there is that as well
20:35 < asdf`> (it even mentions the werkzeug reloader in the docs paragraph about it!)
20:36 < mcdonc> yes i put it there
20:37 < asdf`> (then you might want to fix it, because AFAIR it actually says 'flask', while the reloader is part of werkzeug. But i admit 'flask' is something more people will know)
20:37 < mcdonc> nobody reads docs anyway ;)
20:38 < DasIch> I just wanted to mention I don't care unless someone creates an issue with a valid use case for that but apparently this seems to be it https://github.com/mitsuhiko/werkzeug/issues/58
20:38 < mcdonc> like alex said, it's not entirely crazy to want to use the reloader under supervisor in dev, esp. if your app is reliant on other processes being started
20:39 < mcdonc> i actually dont run my own apps under supervisor, but that's because i don't use a reloader, i just press ctrl-c.. because i'm a savage
20:40 < DasIch> I do use the reloader but I tend to save so often with bad syntax that I end up restarting manually all the time

أعتقد أنها لا تزال ذات صلة.

القيام بـ os.kill(parent_id, signal.SIGTERM) لا يقتل عمليات الأطفال.

لقد واجهت هذه المشكلة أيضًا أثناء إعادة صياغة موقع الاختبار werkzeug.serving . لقد عملت حوله بقتل مجموعة العملية بأكملها: https://github.com/mitsuhiko/werkzeug/blob/a00377315bbf02ec48fdad22c6bb08433fc1e9c1/tests/conftest.py#L158

واجهت نفس المشكلة في Flask مع وضع التصحيح (use_debugger = True). ومع ذلك ، أرى رمز إرجاع 0 في عملية "الأصل". بدون تمكين وضع التصحيح ، يعمل SIGTERM بشكل جيد وتنتهي العملية برمز 143. Python 2.7.5.

لقد تعرضت لهذا الخطأ أيضًا ، في حالتي ، كان docker stop يرسل SIGTERM إلى خادم يعمل بنظام werkzeug (moto) ، ولكن تم تجاهل الخادم ثم قتل عامل الرصيف بـ SIGKILL نتيجة إلى رمز خروج غير صفري.

كان الحل هو تحديد SIGINT (Ctrl + C) كإشارة توقف مفضلة في Dockerfile ( STOPSIGNAL SIGINT ) ، بعد ذلك يتم إغلاق الحاويات بشكل نظيف.

لدي نفس المشكلة أثناء تشغيل تطبيق Flask داخل Docker ؛ ومع ذلك ، لا يزال STOPSIGNAL SIGINT غير كافٍ لإيقاف الحاوية. لا بد لي من استخدام SIGKILL .

لا يمكنني إعادة إنشاء المشكلة. لقد جربت هذا باستخدام حاوية Python الرسمية بعلامة 2.7 و 3.7. لقد استخدمت ملف Dockerfile التالي:

FROM python:2.7

WORKDIR /usr/src/app

RUN pip install click \
                werkzeug \
                sqlalchemy \
                jinja2

COPY . .

RUN python manage-shorty.py initdb

ENTRYPOINT ["python"]

CMD ["manage-shorty.py", "runserver"]

وأنشأوا حاوية من Dockerfile في الدليل examples بالأمر:

 docker build -t werkzeug-examples .

أود بعد ذلك تشغيل الحاوية في الوضع التفاعلي وإلغاء الأمر باستخدام:

$ docker run -it --name werkzeug-example werkzeug-examples
 * Running on http://localhost:5000/ (Press CTRL+C to quit)
 * Restarting with stat
^C

تشغيل docker ps أظهر الخروج بـ 0 :

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                  CREATED              STATUS                      PORTS               NAMES
8c708ea4ef77        werkzeug-examples   "python manage-short…"   About a minute ago   Exited (0) 58 seconds ago                       werkzeug-example

تشغيل الحاوية والتوقف عند docker stop werkzeug-example يخرج أيضًا بـ 0 .

إليك نتيجة إصدار Docker على جهاز الكمبيوتر الذي قمت بتشغيل هذه الأوامر:

Client: Docker Engine - Community
 Version:           18.09.2
 API version:       1.39
 Go version:        go1.10.8
 Git commit:        6247962
 Built:             Sun Feb 10 04:12:39 2019
 OS/Arch:           darwin/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          18.09.2
  API version:      1.39 (minimum version 1.12)
  Go version:       go1.10.6
  Git commit:       6247962
  Built:            Sun Feb 10 04:13:06 2019
  OS/Arch:          linux/amd64
  Experimental:     false

هل يمكنك تقديم مثال يمكنه إعادة إظهار المشكلة التي تواجهها؟

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات