You’re propably looking for the harakiri parameter – if request takes longer than specified harakiri time (in seconds), the request will be dropped and the corresponding worker recycled. For standalone uwsgi (ini config): [uwsgi] http = 0.0.0.0:80 harakiri = 30 … If you have nginx proxy before uwsgi you have to increase timeout as well: … Read more
We’re investigating this problem, tracked in PYTHON-961. You may be able to work around the issue by passing connect=False when creating instances of MongoClient. That defers background connection until the first database operation is attempted, avoiding what I suspect is a race condition between spin up of MongoClient’s monitor thread and multiprocess forking.
I had problems with the accepted solution because my flask app was in a variable called app. You can solve that with putting just this in your wsgi: from module_with_your_flask_app import app as application So the problem was simply that uwsgi expects a variable called application.
You are missing the ProxyFix() middleware component. See the Flask Proxy Setups documentation. There is no need to subclass anything; simply add this middleware component to your WSGI stack: # Werkzeug 0.15 and newer from werkzeug.middleware.proxy_fix import ProxyFix from flask import Flask app = Flask(__name__) app.wsgi_app = ProxyFix(app.wsgi_app, x_proto=1) If you have Flask installed, you … Read more
The issue ended up being uwsgi’s forking. When working with multiple processes with a master process, uwsgi initializes the application in the master process and then copies the application over to each worker process. The problem is if you open a database connection when initializing your application, you then have multiple processes sharing the same … Read more
Just ran into this problem. I don’t know if it’s the same thing that hit your code, but for me the root cause was because I forgot to put name= on the last argument of the url (or path in Django 2.0+) function call. For instance, the following functions throw the error from the question: … Read more
To fix this I did a few things. – Moved all scripts from the home directory to an /var/www/ – created an www group and www user and chown /var/www to www:www Full Instructions Create a user and group www and www sudo groupadd www sudo adduser www -g www create a dir where your … Read more
I see your PYTHONHOME is set to PYTHONHOME = ‘/home/env3/educ’. Try to check if it is really there. The solution for me was to remove the PYTHONHOME environment variable. For you, it can be just that, or setting that variable to another value. This worked on Windows, and would work on Linux for sure. If … Read more
HTTP 499 in Nginx means that the client closed the connection before the server answered the request. In my experience is usually caused by client side timeout. As I know it’s an Nginx specific error code.
Run in development mode by setting the FLASK_ENV environment variable to development. Unhandled errors will show a stack trace in the terminal and the browser instead of a generic 500 error page. export FLASK_ENV=development # use `set` on Windows flask run Prior to Flask 1.0, use FLASK_DEBUG=1 instead. If you’re still using app.run (no longer … Read more