SIGPIPE handling issue?

[keigoi]

Hi! in the code below, the SIGPIPE handler is set to avoid write failures, but I see this is not really good practice for servers (see https://stackoverflow.com/a/7777789/515485 for example).
This part would intercept/change the original signal behaviour of the caller.

https://github.com/geneanet/ocaml-syslog/blob/v2.0.2/syslog.ml#L181-L195

It seems better to ignore SIGPIPE, or just leave the SIGPIPE handler default as-is.

However, it would be a breaking change in anyways for some users, so I'd like to just leave a note for now.

Actually, I had experienced a very subtle issue in the past, where the accidental server socket shutdown invoked this signal handler, and the socket fd was reused by the ocaml-syslog due to the handler behaviour above. The result is that my TCP packets to the server are redirected to the syslogd :p I forgot this phenomenon for years, and suddenly remembered it for now and writing this.

Cheers,

[sagotch]

Shouldn't fallback just restore the old handler after trying to reconnect?

If no thread is involved, this should not "intercept/change the original signal behavior of the caller". If thread is involved, it might "intercept/change the original signal behavior of the caller" indeed, as it already does now. One could imagine a compile-time option to enable or not the SIGPIPE handling.

[keigoi]

After some research, a standard solution seems to be just setting SIGPIPE to SIG_IGN (ignoring it) rather than handling it explicitly (problem above occurs) or leave it as default (process terminates).
Then, the write call on the disconnected syslogd socket will raise the exception (EPIPE) and we could properly handle it in the exception handler.

Indeed it doesn't affect a single-threaded caller.