Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

werkzeug.serving.run_simple does not handle SIGTERM correctly #58

masklinn opened this issue May 9, 2011 · 11 comments

werkzeug.serving.run_simple does not handle SIGTERM correctly #58

masklinn opened this issue May 9, 2011 · 11 comments


Copy link

@masklinn masklinn commented May 9, 2011

When the process receives SIGTERM, it should shut down and exit, with as few operations as possible and without printing anything.

A werkzeug.serving.run_simple process receiving SIGTERM generally result in a return code of 141 (symptom of an un/mishandled SIGPIPE), and when using the reloader the process goes zombie (it has to be killed manually, as the port stays bound).

Adding a signal handler for SIGTERM which simply invokes sys.exit(0) is sufficient to fix the issue (in that there is no more misbehavior of the process), but I am not sure it's the actually correct fix.

Copy link

@mitsuhiko mitsuhiko commented May 24, 2011

I bind a signal handler now when run with reloader. Hope that helps.

@mitsuhiko mitsuhiko closed this May 24, 2011
Copy link

@theduderog theduderog commented Mar 30, 2012

In what version is this fix? This is still a problem in Flask 0.8.

Copy link

@orf orf commented Apr 26, 2012

This is still an issue, its quite annoying when using Flask with an IDE - whenever you stop debugging the process persists and continues to serve requests.

Copy link

@DasIch DasIch commented Jun 2, 2013

I'm reopening this issue as it seems to persist, see the following discussion from IRC today.

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

@DasIch DasIch reopened this Jun 2, 2013
Copy link

@daGrevis daGrevis commented Apr 24, 2014

I think it's still relevant.

Doing os.kill(parent_id, signal.SIGTERM) doesn't kill children processes.

Copy link

@untitaker untitaker commented Oct 7, 2014

I've encountered this issue too while reworking the testsuite for werkzeug.serving. I worked around it by killing the whole process group:

@untitaker untitaker added the bug label Oct 7, 2014
Copy link

@drewdogg drewdogg commented Oct 30, 2015

I ran into this same problem in Flask with debug mode (use_debugger=True). However, I see a return code of 0 on the "parent" process. Without debug mode enabled, SIGTERM works fine and the process exits with code 143. Python 2.7.5.

Copy link

@zyv zyv commented Mar 6, 2018

Got hit by this bug as well, in my case docker stop was sending SIGTERM to werkzeug-powered server (moto), but server ignored and then docker killed it with SIGKILL resulting into a non-zero exit code.

The workaround was to specify SIGINT (Ctrl+C) as a preferred stop signal in Dockerfile (STOPSIGNAL SIGINT), after that the containers shut down cleanly.

Copy link

@agausmann agausmann commented Apr 20, 2018

I have the same problem while running a Flask app inside of Docker; however, STOPSIGNAL SIGINT is still not enough to stop the container. I have to use SIGKILL.

@aenglander aenglander self-assigned this May 7, 2019
Copy link

@aenglander aenglander commented May 7, 2019

I cannot recreate the issue. I have tried this with the official Python container with the 2.7 and 3.7 tag. I used the following Dockerfile:

FROM python:2.7

WORKDIR /usr/src/app

RUN pip install click \
                werkzeug \
                sqlalchemy \

COPY . .

RUN python initdb

ENTRYPOINT ["python"]

CMD ["", "runserver"]

And built a container from the Dockerfile in the examples directory with the command:

 docker build -t werkzeug-examples .

I would then run the container in interactive mode and cancel with:

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

Running docker ps showed it exited with 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

Running the container and stopping with docker stop werkzeug-example also exits with 0.

Here is the result of Docker Version on the computer I ran these commands:

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

Can you provide an example which can reproduce the issue you are experiencing?

Copy link

@aenglander aenglander commented May 12, 2019

Until we can get a reproducible scenario, I will close this as it cannot be reproduced in the latest version of Docker and Werkzeug.

@aenglander aenglander closed this May 12, 2019
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet