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.
If you are using the modern flask run command, none of the options to app.run are used. To disable the reloader completely, pass --no-reload:
FLASK_DEBUG=1 flask run --no-reload
Also, __name__ == '__main__' will never be true because the app isn't executed directly. Use the same ideas from Martijn's answer, except without the __main__ block.
if os.environ.get('WERKZEUG_RUN_MAIN') != 'true':
# do something only once, before the reloader
if os.environ.get('WERKZEUG_RUN_MAIN') == 'true':
# do something each reload
I had the same issue, and I solved it by setting app.debug to False. Setting it to True was causing my __name__ == "__main__" to be called twice.
From Flask 0.11, it's recommended to run your app with flask run rather than python application.py. Using the latter could result in running your code twice.
As stated here :
... from Flask 0.11 onwards the flask method is recommended. The reason for this is that due to how the reload mechanism works there are some bizarre side-effects (like executing certain code twice...)
I am using plugin - python-dotenv
and i will put this on my config file - .flaskenv:
FLASK_RUN_RELOAD=False
and this will avoid flask run twice for me.
One of the possible reason why the Flask app run itself twice is a configuration of WEB_CONCURRENCY setting on Heroku. To set into one, you can write in console
heroku config:set WEB_CONCURRENCY=1
I had the same issue. I solved it by modifying my main and inserting use_reloader=False into it. If anybody is here looking for a workaround for this problem then the below code will get you started, however, you will remove the functionality of changes in code being detected automatically, and restarting the application will not work. You will have to manually stop and restart your application after each edit in code.
if __name__ == '__main__':
app.run(debug=True, use_reloader=False)
Related
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.
If you are using the modern flask run command, none of the options to app.run are used. To disable the reloader completely, pass --no-reload:
FLASK_DEBUG=1 flask run --no-reload
Also, __name__ == '__main__' will never be true because the app isn't executed directly. Use the same ideas from Martijn's answer, except without the __main__ block.
if os.environ.get('WERKZEUG_RUN_MAIN') != 'true':
# do something only once, before the reloader
if os.environ.get('WERKZEUG_RUN_MAIN') == 'true':
# do something each reload
I had the same issue, and I solved it by setting app.debug to False. Setting it to True was causing my __name__ == "__main__" to be called twice.
From Flask 0.11, it's recommended to run your app with flask run rather than python application.py. Using the latter could result in running your code twice.
As stated here :
... from Flask 0.11 onwards the flask method is recommended. The reason for this is that due to how the reload mechanism works there are some bizarre side-effects (like executing certain code twice...)
I am using plugin - python-dotenv
and i will put this on my config file - .flaskenv:
FLASK_RUN_RELOAD=False
and this will avoid flask run twice for me.
One of the possible reason why the Flask app run itself twice is a configuration of WEB_CONCURRENCY setting on Heroku. To set into one, you can write in console
heroku config:set WEB_CONCURRENCY=1
I had the same issue. I solved it by modifying my main and inserting use_reloader=False into it. If anybody is here looking for a workaround for this problem then the below code will get you started, however, you will remove the functionality of changes in code being detected automatically, and restarting the application will not work. You will have to manually stop and restart your application after each edit in code.
if __name__ == '__main__':
app.run(debug=True, use_reloader=False)
I have two different Flask project. I want to run them on server on different link.
Currently I saw at a time one project I can see running.
I tried running on same port with different link, and also with different port. But I see it runs only one project at a time.
Project 1
if __name__ == '__main__':
app.run(host="0.0.0.0", port=5001,debug = True)
Project 2
I tried running
export FLASK_APP=app.py
flask run --host 0.0.0.0 --port 5000
Also this way
if __name__ == '__main__':
app.run(host="0.0.0.0", port="5000",debug = True)
I recently did a parallel threading operation with my own website in Flask. So I completely understand your confusion, though I'm going to explain this the best of my abilities.
When creating parallel operations, it's best to use multi-threading. Basically multi-threading is meant for splitting operations up and doing them simultaneously on the CPU. Though this must be supported by the CPU, which most by today are supporting Multi-Threading.
Anyways, with the application. I initialized the Flask Application classes to share the data between all the threads, by using the main thread as the memory handler. Afterwards, I created the pages. Then within the initialization 'if statement'(if __name__ == '__main__') - Known as a driver class in other languages. I initialized and started the threads to do there parts of the application.
Notes:
Flask doesn't allow debug mode to be executed while not on the Main Thread. Basically meaning you cannot use the multi-threading on the Flask Apps when debugging the application, which is no problem. VSCode has a great output console to give me enough information to figure out the issues within the application. Though... sometimes thread error finding can be.. painful at times, it's best to watch your steps when debugging.
Another thing is you can still operate the threaded feature on Flask. Which I like to use on any Flask Application I make, because it allows better connection for the clients. For example, thread is disabled; the client connects and holds up the main thread, which holds it for a millisecond then releases it. Having threaded enabled; allows the clients to open and release multiple requests. Instead of all the clients piping through one thread.
Why would that be important? Well, if a client runs a heavy script that has to do operations on the local host machine, then that page's request query will be taking a larger amount of time. In returns, makes the client hold that main thread pipe, so therefore no-one else could connect.
My Code for your Issue:
import threading
from flask import Flask
# My typical setup for a Flask App.
# ./media is a folder that holds my JS, Imgs, CSS, etc.
app1 = Flask(__name__, static_folder='./media')
app2 = Flask(__name__, static_folder='./media')
#app1.route('/')
def index1():
return 'Hello World 1'
#app2.route('/')
def index2():
return 'Hello World 2'
# With Multi-Threading Apps, YOU CANNOT USE DEBUG!
# Though you can sub-thread.
def runFlaskApp1():
app1.run(host='127.0.0.1', port=5000, debug=False, threaded=True)
def runFlaskApp2():
app2.run(host='127.0.0.1', port=5001, debug=False, threaded=True)
if __name__ == '__main__':
# Executing the Threads seperatly.
t1 = threading.Thread(target=runFlaskApp1)
t2 = threading.Thread(target=runFlaskApp2)
t1.start()
t2.start()
PS: Run this app by doing python app.py instead of
export FLASK_APP=app.py
flask run --host 0.0.0.0 --port 5000
Hope this helps you, and happy developing!
So I'm trying to write a Flask app that has a block of code running once every ten minutes, pulling down and processing a file. The way I currently trigger that block of code to run is a loop that sees if the delta between the current time and the last time the block of code ran is greater than ten minutes. Multiprocessing is being used to run the loop concurrently with what Flask is doing, all set up in the if __name__ == "__main__": portion of my Flask app.
Unfortunately, since the app is being run using Gunicorn (using Heroku to run the app), if __name__ == "__main__": doesn't resolve as true and the loop doesn't even start. Setting up Multiprocess in something like if True: only throws errors and doing if __name__ =! "__main__": throws no errors but locks Flask up in the loop, meaning that Multiprocess isn't really doing what it's supposed to. Really curious as to why this is, but my larger question is if there is a better way to run my block of code once every ten minutes where I can still easily pass the results of the code to Flask or get Multiprocess to run correctly and would you mind elaborating on either? Something that's built into Flask, maybe similar to #app.before_first_request, where an external trigger isn't required would be nice. I feel as if I've overlooked something really simple and over complicated what I'm doing as a result.
A simplified version of my code is as follows and works when not being handled by Gunicorn on my local machine:
import time
from flask import Flask, request, jsonify
from multiprocessing import Process, Value
app = Flask(__name__)
#app.route('/')
def webhook:
respond_to_requests()
def record_loop(loop_on):
while True:
if loop_on.value == True:
check_time_and_run_code()
time.sleep(1)
if __name__ == "__main__":
recording_on = Value('b', True)
p = Process(target=record_loop, args=(recording_on,))
p.start()
app.run(debug=True, use_reloader=False)
p.join()
The Procfile I'm using on Heroku to run this app with Gunicorn contains web: gunicorn app:app --log-file=-
Thanks in advance for the help! :D
You seem to doing a background task in a web process. Web processes are meant to handle incoming requests. Background tasks should be run separately.
You can use Heroku Scheduler or a custom clock process to run background tasks at regular intervals.
I've read some documentation online about how to do remote debugging with PyCharm - https://www.jetbrains.com/help/pycharm/remote-debugging.html
But there was one key issue with that for what I was trying to do, with my setup - Nginx connecting to uWSGI, which then connects to my Flask app. I'm not sure, but setting up something like,
import sys
sys.path.append('pycharm-debug.egg')
import pydevd
pydevd.settrace('localhost', port=11211,
stdoutToServer=True, stderrToServer=True,
suspend=False)
print 'connected'
from wsgi_configuration_module import app
My wsgi_configuration_module.py file is the uWSGI file used in Production, i.e. no debug.
Connects the debugger to the main/master process of uWSGI, which is run once only, at uWSGI startup / reload, but if you try to set a breakpoint in code blocks of your requests, I've found it to either skip over it, or hang entirely, without ever hitting it, and uWSGI shows a gateway error, after timeout.
The problem here, as far as I see it is exactly that last point, the debugger connects to uWSGI / the application process, which is not any of the individual request processes.
To solve this, from my situation, it needed 2 things changed, 1 of which is the uWSGI configuration for my app. Our production file looks something like
[uwsgi]
...
master = true
enable-threads = true
processes = 5
But here, to give the debugger (and us) an easy time to connect to the request process, and stay connected, we change this to
[uwsgi]
...
master = true
enable-threads = false
processes = 1
Make it the master, disable threads, and limit it to only 1 process - http://uwsgi-docs.readthedocs.io/en/latest/Options.html
Then, in the startup python file, instead of setting the debugger to connect when the entire flask app starts, you set it to connect in a function decorated with the handy flask function, before_first_request http://flask.pocoo.org/docs/0.12/api/#flask.Flask.before_first_request, so the startup script changes to something like,
import sys
import wsgi_configuration_module
sys.path.append('pycharm-debug.egg')
import pydevd
app = wsgi_configuration_module.app
#app.before_first_request
def before_first_request():
pydevd.settrace('localhost', port=11211,
stdoutToServer=True, stderrToServer=True,
suspend=False)
print 'connected'
#
So now, you've limited uWSGI to no threads, and only 1 process to limit the chance of any mixup with them and the debugger, and set pydevd to only connect before the very first request. Now, the debugger connects (for me) successfully once, at the first request in this function, prints 'connected' only once, and from then on breakpoints connect in any of your request endpoint functions without issue.
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.
If you are using the modern flask run command, none of the options to app.run are used. To disable the reloader completely, pass --no-reload:
FLASK_DEBUG=1 flask run --no-reload
Also, __name__ == '__main__' will never be true because the app isn't executed directly. Use the same ideas from Martijn's answer, except without the __main__ block.
if os.environ.get('WERKZEUG_RUN_MAIN') != 'true':
# do something only once, before the reloader
if os.environ.get('WERKZEUG_RUN_MAIN') == 'true':
# do something each reload
I had the same issue, and I solved it by setting app.debug to False. Setting it to True was causing my __name__ == "__main__" to be called twice.
From Flask 0.11, it's recommended to run your app with flask run rather than python application.py. Using the latter could result in running your code twice.
As stated here :
... from Flask 0.11 onwards the flask method is recommended. The reason for this is that due to how the reload mechanism works there are some bizarre side-effects (like executing certain code twice...)
I am using plugin - python-dotenv
and i will put this on my config file - .flaskenv:
FLASK_RUN_RELOAD=False
and this will avoid flask run twice for me.
One of the possible reason why the Flask app run itself twice is a configuration of WEB_CONCURRENCY setting on Heroku. To set into one, you can write in console
heroku config:set WEB_CONCURRENCY=1
I had the same issue. I solved it by modifying my main and inserting use_reloader=False into it. If anybody is here looking for a workaround for this problem then the below code will get you started, however, you will remove the functionality of changes in code being detected automatically, and restarting the application will not work. You will have to manually stop and restart your application after each edit in code.
if __name__ == '__main__':
app.run(debug=True, use_reloader=False)