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
in core/uwsgi.c a handler for a SIGPIPE signal is registered:
if (!uwsgi.ignore_sigpipe) {
signal(SIGPIPE, (void *) &warn_pipe);
}
We have a systemd-based uWSGI setup which means that uWSGI is started by systemd and the default behavior in this case is to pipe its stdout and stderr to systemd-journald.
When journald is restarted it raises a SIGPIPE. A similar issue can be found here: cybozu-go/well#13
Since uWSGI tries to handle a SIGPIPE by logging it, the log message ends up in a broken pipe which in turn raises a SIGPIPE and we are stuck in an infinite loop.
The ignore-sigpipe config option (as seen in the if statement above) can be used to avoid this but it might be better to just ignore the SIGPIPE signal by default.
The text was updated successfully, but these errors were encountered:
Hi, thanks a lot for reporting (eventually feel free to make a pull request in systemd-related uwsgi-docs). Unfortunately not handling it could lead to unreported errors in other plugins that do not have a solid i/o error checking
in core/uwsgi.c a handler for a SIGPIPE signal is registered:
We have a systemd-based uWSGI setup which means that uWSGI is started by systemd and the default behavior in this case is to pipe its stdout and stderr to systemd-journald.
When journald is restarted it raises a SIGPIPE. A similar issue can be found here: cybozu-go/well#13
Since uWSGI tries to handle a SIGPIPE by logging it, the log message ends up in a broken pipe which in turn raises a SIGPIPE and we are stuck in an infinite loop.
The
ignore-sigpipe
config option (as seen in the if statement above) can be used to avoid this but it might be better to just ignore the SIGPIPE signal by default.The text was updated successfully, but these errors were encountered: