-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Error handling request (no URI read) #3207
Comments
Got any context; when does this get triggered? I partially reverted 1ccebab (meant to silence exceptions below |
Hello, we're experiencing an issue in our production environment, and since we have limited information, diagnosing it is challenging. The problem occurs randomly, and we're using Python version 3.8.18 and Django version 4.2.12. |
|
Hello,
|
Your logs are upside down 🙃 - but yes, you did find something. There are various issues around the In 4023228 all BaseException handling was forced into the parent class, and because exceptions handled from connections that had not yet received a full request line were previously not logged, that greenlet-specific BaseException suppression looks(²) neutralized. I think some class hierarchy respecting way of moving just those two would do the trick, but would prefer a solution that undoes the imho too broad except block in favour of only handling those not-quite-fatal BaseException in our area of responsibility. (² I'll have to write a few tests to tell. gevent exception propagation is somewhat special.) |
Thank you, @pajod, for the detailed explanation. We will attempt to disable max_requests. Have a wonderful week! P.S. Sorry for the logs 🙃 |
Hi @pajod , thank you for looking into this! I have the same issue here. Is there any reason for exposing Thanks! |
FYI, I am describing a related bug. I am not opening a new issue so as not to make too much noise, but I would be interested about comments from the maintainers |
Hi, this might be completely unrelated, but I was seeing a similar error message:
In my case, I was playing around with sendfile/X-Accel-Redirect and had a Django view like this: def login_required_media_view(request, path):
response = HttpResponse(status=200)
response["Content-Type"] = ""
response["X-Accel-Redirect"] = "/media/" + quote(path)
return response
Just in case this is useful for someone here. |
@jeverling It is related - that is how the exception handling looks like without the added gevent complexity. Useful for others to find this issue. Where they can learn that they can revert 0b10cba (to silence the error log again) or 4023228 (to return to the previous exception handling) before a proper bugfix release is issued. (At this time I do not suggest a downgrade.) |
I don't understand this issue. Gunicorn responds appropriately when queried directly with wget/curl, but fails when there's a webserver inbetween. Is that correct? How could such behavior be correct? My nginx configuration is using the default uwsgi_params in the example documentation https://docs.nginx.com/nginx/admin-guide/web-server/app-gateway-uwsgi-django/ |
I can reproduce this issue when I use chrome and after default timeout it through error, but in case of postman or safari I am not seeing it. |
I am facing the same problem except that the error shows up intermittently. I am running
As you can see, we get a timeout and suddenly an exception shows up. When this happens, there is a temporary Internal Server Error due to this but it goes away once another worker is up. |
I have the same problem:
Even with a substantial timeout:
Software versions:
UPDATE: With this setup on NGINX, the timeout stopped occurring:
|
For those in a position to review and/or test it: you are welcome to provide feedback on my suggested patch: #3275 |
Has anyone identified what the actual originating issue is that is causing the worker timeout? I see the PR addresses the exception bubbling, but I've yet to find any threads where anyone has identified what the actual cause of this is. I'm seeing the same issue where a worker will handle the request, the browser receives the data and request ends there, but then the worker dies after the set Setting |
Considering that using raw http or proxy protocol with nginx doesn't generate problems, while uwsgi_pass does, this problem is contained to using wsgi. |
After upgrading from version 20.1.0 to 22.0.0, we have encountered "Error handling request (no URI read)" errors.
/var/log/messages
gunicorn.conf.py
Env:
The text was updated successfully, but these errors were encountered: