I'm using Flask for developing a website and while in development I run flask using the following file:
#!/usr/bin/env python
from datetime import datetime
from app import app
import config
if __name__ == '__main__':
print('################### Restarting @', datetime.utcnow(), '###################')
app.run(port=4004, debug=config.DEBUG, host='0.0.0.0')
When I start the server, or when it auto-restarts because files have been updated, it always shows the print line twice:
################### Restarting @ 2014-08-26 10:51:49.167062 ###################
################### Restarting @ 2014-08-26 10:51:49.607096 ###################
Although it is not really a problem (the rest works as expected), I simply wonder why it behaves like this? Any ideas?
The Werkzeug reloader spawns a child process so that it can restart that process each time your code changes. Werkzeug is the library that supplies Flask with the development server when you call app.run()
.
See the restart_with_reloader()
function code; your script is run again with subprocess.call()
.
If you set use_reloader
to False
you'll see the behaviour go away, but then you also lose the reloading functionality:
app.run(port=4004, debug=config.DEBUG, host='0.0.0.0', use_reloader=False)
You can disable the reloader when using the flask run
command too:
FLASK_DEBUG=1 flask run --no-reload
You can use the werkzeug.serving.is_running_from_reloader
function if you wanted to detect when you are in the reloading child process:
from werkzeug.serving import is_running_from_reloader
if is_running_from_reloader():
print(f"################### Restarting @ {datetime.utcnow()} ###################")
However, if you need to set up module globals, then you should instead use the @app.before_first_request
decorator on a function and have that function set up such globals. It'll be called just once after every reload when the first request comes in:
@app.before_first_request
def before_first_request():
print(f"########### Restarted, first request @ {datetime.utcnow()} ############")
Do take into account that if you run this in a full-scale WSGI server that uses forking or new subprocesses to handle requests, that before_first_request
handlers may be invoked for each new subprocess.