Can writes to a datagram socket ever raise SIGPIPE?

Question

I'm working with some code that needs to be safe against killing the caller due to SIGPIPE, but the only socket writes it's performing are going to datagram sockets (both UDP and Unix domain datagram sockets). Do I need to worry about SIGPIPE? I'm using connect on the socket, but preliminary testing (on Linux) showed that I just get ECONNREFUSED on send if there's nobody listening on the Unix domain socket. Not sure what happens with UDP.

I can wrap the whole thing in hacks to get rid of SIGPIPE, but if it's a non-issue I'd rather save the overhead and keep the code complexity down.

Sheronsherourd

I'm going to give you a bad answer. I think I've seen it happen before when starting an application as the Linux system was booting. I can't say if it was definitely a datagram socket that was the underlying issue, but as far as I know we didn't use any TCP sockets for that application. Just a test case for you to consider if it might apply to you. – Archaean

I think I might just arrange things to use sendto rather than write so I can pass that flag that disables SIGPIPE. – Sheronsherourd

Answer 1

The answer is in the specification for send:

[EPIPE] The socket is shut down for writing, or the socket is connection-mode and is no longer connected. In the latter case, and if the socket is of type SOCK_STREAM or SOCK_SEQPACKET and the MSG_NOSIGNAL flag is not set, the SIGPIPE signal is generated to the calling thread.

http://pubs.opengroup.org/onlinepubs/9699919799/functions/send.html

Thus, no, writes to datagram sockets do not generate SIGPIPE or an EPIPE error.

Sheronsherourd

Doesn't the text above actually say that you could get it in UDP if "the socket is shut down for writing" (whatever that means)? – Jolandajolanta

@T.E.D.: Perhaps (if shutdown-for-write works on a datagram socket), but that's a condition that would not happen without programmer intent or error. It's not caused by the peer. – Sheronsherourd

Answer 2

The open group is one thing, and Apple is another. It is definitely possible to get a SIGPIPE on iOS when writing to a dead UDP socket, as some of my crash logs revealed lately. iOS tends to close UDP sockets while the app is in the background, writing to these sockets can pop a SIGPIPE.
From my crash log (courtesy of testflightapp):

Exception Latest Victim Occurrences
SIGPIPE
2 libsystem_c.dylib 0x32df47ec _sigtramp + 48
3 instant talk 0x0005b10e -[IPRSNetDatagramSocket send:size:to:] (iprs_iphone_net.m:671)...

Don't recall this happening on Linux, Solaris or Windows - though I never tried to close a socket and then write to it.

Superfluid

Closing a socket then writing to it will not give SIGPIPE or EPIPE; it will give EBADF. iOS must be putting the socket into some special nonstandard mode to cause SIGPIPE. In any case my question was tagged POSIX because I was looking for the standard behavior, but your answer is informative too. – Sheronsherourd

Answer 3

According to man 2 write on my Debian box,

EPIPE: fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)

It appears that it is possible to get SIGPIPE when writing to a socket, but it's not clear whether it can happen for UDP sockets specifically.

Delegation

The man page for send is somewhat more specific, but it's not as clear as what POSIX says about send.. – Sheronsherourd

Indeed, @R... I upvoted and your answer seconds after you posted it. I just meant to get the ball rolling with my post. – Delegation