[uwsgi]
socket=/home/zulip/deployments/uwsgi-socket
module=zproject.wsgi:application
chdir=/home/zulip/deployments/current/
master=true
chmod-socket=700
chown-socket=zulip:zulip
processes=<%= @uwsgi_processes %>
harakiri=20
buffer-size=<%= @uwsgi_buffer_size %>
listen=<%= @uwsgi_listen_backlog_limit %>
post-buffering=4096
env= LANG=en_US.UTF-8
uid=zulip
gid=zulip

[uwsgi]
socket=/home/zulip/deployments/uwsgi-socket
module=zproject.wsgi:application
chdir=/home/zulip/deployments/current/
master=true
chmod-socket=700
chown-socket=zulip:zulip
processes=<%= @uwsgi_processes %>
harakiri=20
buffer-size=<%= @uwsgi_buffer_size %>
listen=<%= @uwsgi_listen_backlog_limit %>
post-buffering=4096
env= LANG=en_US.UTF-8
uid=zulip
gid=zulip

ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

Stop generating IOError and SIGPIPE on client close.
uwsgi: Stop generating IOError and SIGPIPE on client close.

Clients that close their socket to nginx suddenly also cause nginx to close
its connection to uwsgi.  When uwsgi finishes computing the response,
it thus tries to write to a closed socket, and generates either
IOError or SIGPIPE failures.

Since these are caused by the _client_ closing the connection
suddenly, they are not actionable by the server.  At particularly high
volumes, this could represent some sort of server-side failure;
however, this is better detected by examining status codes at the
loadbalancer.  nginx uses the error code 499 for this occurrence:
https://httpstatuses.com/499

Stop uwsgi from generating this family of exception entirely, using
configuration for uwsgi[1]; it documents these errors as "(annoying),"
hinting at their general utility."

[1] https://uwsgi-docs.readthedocs.io/en/latest/Options.html#ignore-sigpipe
