While writing a test on work I hit a bug in perl. Normally if recv is interrupted by a signal it returns undef and sets $! to EINTR. In my case I had failure because $! was set to zero. It took me some time to reproduce conditions in which it happens, but finally I've got it boiled down to the following:

use strict;
use warnings;
use IO::Socket::INET;

my $srv = IO::Socket::INET->new(
    LocalAddr => '127.0.0.1',
    LocalPort => 7777,
    ReuseAddr => 1,
    Listen    => 1,
) or die $!;

my $sock = IO::Socket::INET->new(
    PeerAddr => '127.0.0.1',
    PeerPort => 7777,
) or die $!;
my $cli = $srv->accept or die $!;

my $sock2 = IO::Socket::INET->new(
    PeerAddr => '127.0.0.1',
    PeerPort => 7777,
) or die $!;
my $cli2 = $srv->accept or die $!;

local $SIG{ALRM} = sub { $sock->send( "hi\n", 0 ); };

alarm 2;

my $res;
use Data::Dumper;
$res = $sock2->recv( my $buf, 1024 ) or die Dumper [ $res, $!, 0 + $!,
+ ];
__END__
$VAR1 = [
          undef,
          '',
          '0'
        ];
[download]

The trick was to establish two connections to the same peer, with only one connection I was getting correct result. Apparently this was fixed somewhere in 5.13, because if I run this with 5.14.2 it returns expected result, which is:

$VAR1 = [
          undef,
          'Interrupted system call',
          '4'
        ];
[download]

That's the downside of using stable Debian -- you're hitting bugs that were already found and fixed years ago. I couldn't find it in RT though, so if somebody by any chance know what I'm talking about and can point me to the ticket or commit in git it would be much appreciated. I naturally fixed the problem in my module with:

         my $ret = $self->{_socket}->recv( my $buffer, 131072 );
         unless ( defined $ret ) {
-            next if $! == EINTR;
+            next if $! == EINTR or $! == 0;
             confess "Error reading reply from server: $!";
         }
[download]

Update: for the record, the commit that fixes the problem is d016601