Re^4: SIG{'PIPE'} and pipe timeout

[Marcello]

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)

[zentara]

Hi, I went to http://groups.google.com 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.

[Marcello]

Thanks!

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