<p>werkzeug.serving.run_simple ne gère pas correctement SIGTERM</p>

Créé le 9 mai 2011  ·  11Commentaires  ·  Source: pallets/werkzeug

Lorsque le processus reçoit SIGTERM , il doit s'arrêter et se terminer, avec le moins d'opérations possible et sans rien imprimer.

Un processus werkzeug.serving.run_simple recevant SIGTERM aboutit généralement à un code retour de 141 (symptôme d'un SIGPIPE non / mal géré), et lors de l'utilisation du rechargeur, le processus devient zombie (il a à tuer manuellement, car le port reste lié).

L'ajout d'un gestionnaire de signal pour SIGTERM qui invoque simplement sys.exit(0) est suffisant pour résoudre le problème (en ce sens qu'il n'y a plus de mauvaise conduite du processus), mais je ne suis pas sûr que ce soit la solution réellement correcte.

bug

Commentaire le plus utile

J'ai également été touché par ce bogue, dans mon cas, docker stop envoyait SIGTERM au serveur alimenté par werkzeug (moto), mais le serveur a ignoré puis docker l'a tué avec SIGKILL résultant dans un code de sortie différent de zéro.

La solution de contournement était de spécifier SIGINT (Ctrl + C) comme signal d'arrêt préféré dans Dockerfile ( STOPSIGNAL SIGINT ), après quoi les conteneurs s'éteignent proprement.

Tous les 11 commentaires

Je lie un gestionnaire de signal maintenant lorsqu'il est exécuté avec un rechargeur. J'espère que ça t'as aidé.

Dans quelle version est ce correctif? C'est toujours un problème dans Flask 0.8.

C'est toujours un problème, c'est assez ennuyeux lors de l'utilisation de Flask avec un IDE - chaque fois que vous arrêtez de déboguer le processus persiste et continue de servir les requêtes.

Je rouvre ce problème car il semble persister, voir la discussion suivante d'IRC aujourd'hui.

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

Je pense que c'est toujours d'actualité.

Faire os.kill(parent_id, signal.SIGTERM) ne tue pas les processus enfants.

J'ai également rencontré ce problème en retravaillant la suite de tests pour werkzeug.serving . J'ai contourné ce problème en tuant tout le groupe de processus: https://github.com/mitsuhiko/werkzeug/blob/a00377315bbf02ec48fdad22c6bb08433fc1e9c1/tests/conftest.py#L158

J'ai rencontré ce même problème dans Flask avec le mode débogage (use_debugger = True). Cependant, je vois un code de retour de 0 sur le processus «parent». Sans le mode débogage activé, SIGTERM fonctionne correctement et le processus se termine avec le code 143. Python 2.7.5.

J'ai également été touché par ce bogue, dans mon cas, docker stop envoyait SIGTERM au serveur alimenté par werkzeug (moto), mais le serveur a ignoré puis docker l'a tué avec SIGKILL résultant dans un code de sortie différent de zéro.

La solution de contournement était de spécifier SIGINT (Ctrl + C) comme signal d'arrêt préféré dans Dockerfile ( STOPSIGNAL SIGINT ), après quoi les conteneurs s'éteignent proprement.

J'ai le même problème lors de l'exécution d'une application Flask à l'intérieur de Docker; cependant, STOPSIGNAL SIGINT n'est toujours pas suffisant pour arrêter le conteneur. Je dois utiliser SIGKILL .

Je ne peux pas recréer le problème. J'ai essayé cela avec le conteneur Python officiel avec les balises 2.7 et 3.7. J'ai utilisé le Dockerfile suivant:

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"]

Et construit un conteneur à partir du Dockerfile dans le répertoire examples avec la commande:

 docker build -t werkzeug-examples .

Je lancerais ensuite le conteneur en mode interactif et j'annulerais avec:

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

L'exécution de docker ps montré avec 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

L'exécution du conteneur et l'arrêt avec docker stop werkzeug-example se terminent également avec 0 .

Voici le résultat de la version Docker sur l'ordinateur sur lequel j'ai exécuté ces commandes:

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

Pouvez-vous fournir un exemple qui peut reproduire le problème que vous rencontrez?

Jusqu'à ce que nous puissions obtenir un scénario reproductible, je vais le fermer car il ne peut pas être reproduit dans la dernière version de Docker et Werkzeug.

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

Nessphoro picture Nessphoro  ·  6Commentaires

KangOl picture KangOl  ·  16Commentaires

ngaya-ll picture ngaya-ll  ·  8Commentaires

c17r picture c17r  ·  4Commentaires

davidism picture davidism  ·  9Commentaires