6

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 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. – Jeff Apr 14 '11 at 01:25
  • I think I might just arrange things to use `sendto` rather than `write` so I can pass that flag that disables `SIGPIPE`. – R.. GitHub STOP HELPING ICE Apr 14 '11 at 01:54

3 Answers3

12

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.

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • 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)? – T.E.D. Feb 10 '17 at 21:35
  • @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. – R.. GitHub STOP HELPING ICE Feb 10 '17 at 21:59
8

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.

Moshe Gottlieb
  • 3,963
  • 25
  • 41
  • 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. – R.. GitHub STOP HELPING ICE Sep 12 '12 at 13:31
1

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.

ikegami
  • 367,544
  • 15
  • 269
  • 518