SIGPIPE when writing data to a server that doesn't want it

[djmitche]

In GothenburgBitFactory/taskwarrior#3624, user misconfiguration means that we are sending a pretty big request body to a server that's not interested, and presumably drops the TCP connection. Ideally this should result in a Result::Err and we can report it back to the user, but instead the process gets a SIGPIPE and exits with a nonzero status but no console output.

From the backtrace in that bug, it appears that rustls is using writev and not using MSG_NOSIGNAL as ureq does. I see @jsha answered in rustls/rustls#1371 regarding a (somewhat racy) way of detecting the server closing the connection, but perhaps this doesn't cover writes via rustls?

Is there a preferred/recommended way to avoid this?

[algesten]

@djmitche If you have an easy test case for this, it would be very interesting to run it with the main branch where we have the ureq 3.x rewrite. I don't expect any behavior changes if the error arises deep in rustls, but it's interesting to know for sure.

[djmitche]

Huh, I can reproduce the SIGPIPE with just ureq, as visible in gdb. But it appears to be handled, and I get a Result::Err. So this must be something particular about pipe configuration in my application. I'll keep looking.

[djmitche]

Ah, rust-lang/rust#62569 looks related, and I see the following in the trace for a run of a Rust binary:

rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f855dd3b090}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0

So, this isn't a ureq issue.

[algesten]

I had no idea Rust did this. Thanks!