in reply to Re^3: SIG{'PIPE'} and pipe timeout
in thread SIG{'PIPE'} and pipe timeout

Here is my code:
my $child = my $parent = my $pid = undef; # Create a socket pair from IPC (both ways) if (!socketpair($child, $parent, AF_UNIX, SOCK_STREAM, PF_UNSPEC)) + { die "socketpair failed: ".$!; } else { # Flush messages immediately $child->autoflush(1); $parent->autoflush(1); if (!defined($pid = fork())) { die "Fork failed: ".$!; } elsif ($pid == 0) { close($child); # Here the process will carry out the work, and also write + to the 'pipe' # It will only exit this loop upon SIGTERM # Close the pipe with the parent close($parent); exit 0; } else { close($parent); } }
The pipe signal only occurs after a long period of inactivity on the client side, not on the server side (which also uses the 'pipe' to send messages to the client)

Replies are listed 'Best First'.
Re^5: SIG{'PIPE'} and pipe timeout
by zentara (Archbishop) on Feb 07, 2006 at 16:30 UTC
    Hi, I went to and searched for "SIG PIPE socket" and got a bunch of hits about odd SIG{PIPES} on sockets.

    One of the better responses said that you should just set $SIG{PIPE} = 'IGNORE'; as a good precaution. The causes can vary, but one reply said

    The kernel will post a SIGPIPE to a process when it writes to a pipe, fifo, or network endpoint that is no longer open for reading. The primary reason for this behavior is to expeditiously terminate processes that write to their stdout stream but do not check the exit status of the write() call. For programs that are well behaved (i.e., those which check the status of calls to write(2)) it is best to simply set SIGPIPE to be ignored.

    So maybe your client closes up(goes to sleep?) after a long period of inactivity, maybe you should strobe it every hour with a newline or something.

    I'm not really a human, but I play one on earth. flash japh

      I will search there too. So probably it is rather harmless and can be IGNORE'ed.