You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are uWSGI options to ignore the errors, which would be fine if the error were caused by a client closing the connection before the response was written. However, it seems the error can also be caused by a timeout, in which case we'd want to change our timeout configuration in Apache and in uWSGI.
For now, this issue just creates noise in Sentry. We're not aware of it affecting a user (viz. timeout potential cause).
i see these errors in zulip django.log from time to time:
Wed Jun 2 05:54:14 2021 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/v1/users/me/1/topics? (ip 5.147.234.117) !!!
Wed Jun 2 05:54:14 2021 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 306] during GET /api/v1/users/me/1/topics? (5.147.234.117)
OSError: write error
Wed Jun 2 05:54:14 2021 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/v1/users/me/1/topics? (ip 5.147.234.117) !!!
Wed Jun 2 05:54:14 2021 - uwsgi_response_writev_headers_and_body_do(): Broken pipe [core/writer.c line 306] during GET /api/v1/users/me/1/topics? (5.147.234.117)
OSError: write error
Closing as errors occur quite rarely based on Sentry for cove-ocds.
If we set up the Data Review Tools at dedicated subdomains instead of proxying as part of either #266 or #145, then one potential cause for this error might go away.
We occasionally see errors reported to Sentry from uWSGI as simply "OSError: write error".
When looking in
/var/log/uwsgi/app/
log files, we get more detail:There are uWSGI options to ignore the errors, which would be fine if the error were caused by a client closing the connection before the response was written. However, it seems the error can also be caused by a timeout, in which case we'd want to change our timeout configuration in Apache and in uWSGI.
For now, this issue just creates noise in Sentry. We're not aware of it affecting a user (viz. timeout potential cause).
There is a lengthy uWSGI issue here: unbit/uwsgi#1623
The text was updated successfully, but these errors were encountered: