uWSGI errors: `OSError: write error`

1

Dear Indico community,

uwsgi.log contains several errors:

Tue Nov 25 09:45:40 2025 - mem-collector thread started for worker 1
uwsgi_response_write_body_do() TIMEOUT !!!
OSError: write error
uwsgi_response_write_body_do() TIMEOUT !!!
OSError: write error
uwsgi_response_write_body_do() TIMEOUT !!!
OSError: write error
Tue Nov 25 09:54:19 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /dist/css/jquery.ac0a9a35.css (ip 141.14.30.x) !!!
Tue Nov 25 09:54:19 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /dist/css/jquery.ac0a9a35.css (141.14.30.x)
OSError: write error
Tue Nov 25 09:54:19 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /fonts/icomoon/icomoon__v58bf5496.woff (ip 141.14.30.x) !!!
Tue Nov 25 09:54:19 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /fonts/icomoon/icomoon__v58bf5496.woff (141.14.30.x)
OSError: write error
Tue Nov 25 09:54:19 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /fonts/roboto/roboto-bold-webfont__v8a318ea0.woff2 (ip 141.14.30.x) !!!
Tue Nov 25 09:54:19 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /fonts/roboto/roboto-bold-webfont__v8a318ea0.woff2 (141.14.30.x)
OSError: write error
Tue Nov 25 09:54:19 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /fonts/liberation_sans/liberationsans-bold-webfont__vba8788b9.woff2 (ip 141.14.30.x) !!!
Tue Nov 25 09:54:19 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /fonts/liberation_sans/liberationsans-bold-webfont__vba8788b9.woff2 (141.14.30.x)
OSError: write error
...The work of process 101582 is done (max requests reached (2500 >= 2500)). Seeya!
worker 1 killed successfully (pid: 101582)
Respawned uWSGI worker 1 (new pid: 124116)
Tue Nov 25 10:13:04 2025 - mem-collector thread started for worker 1
...The work of process 101314 is done (max requests reached (2500 >= 2500)). Seeya!
worker 2 killed successfully (pid: 101314)
Respawned uWSGI worker 2 (new pid: 124869)
Tue Nov 25 10:14:03 2025 - mem-collector thread started for worker 2
Tue Nov 25 10:19:01 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /dist/css/react.714d0dbe.css (ip 141.14.22.125) !!!
Tue Nov 25 10:19:01 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /dist/css/react.714d0dbe.css (141.14.22.125)
OSError: write error
Tue Nov 25 10:19:01 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /images/indico_small.png (ip 141.14.22.125) !!!
Tue Nov 25 10:19:01 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /images/indico_small.png (141.14.22.125)
OSError: write error
invalid request block size: 24548 (max 20480)...skip
Tue Nov 25 10:41:46 2025 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /images/indico_small.png (ip 141.14.22.y) !!!
Tue Nov 25 10:41:46 2025 - uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 429] during GET /images/indico_small.png (141.14.22.y)
OSError: write error

Are these common errors, and can I do something about them?

Kind regards,

Paul

2

Is anything broken? If not I would ignore them. Probably related to clients closing the connection while st ill receiving data…

3

Yes, unfortunately, something seems broken. https://events.molgen.mpg.de often does not load for me, and

uwsgi_response_write_body_do() TIMEOUT !!!
OSError: write error
uwsgi_response_write_body_do() TIMEOUT !!!
OSError: write error

shows up in the logs.

4

Check if there is a high bot load ( these tend to also drop connections prematurely) in the nginx/apache logs. We had bot requesting 100s of tex-generated pdfs within a very short time frame (from many different src ips) lastly, causing a DOS-like behavior.

5

You should check your setup, as in the standard setup all these files should be served from the nginx/apache in front your uwsgi. Hard to debug further without more details about your setup.