Well, yanking your network cable could certainly cause TCP to take 8 minutes to decide that the link is down. But if select has said that you can read from the socket, then sysread shouldn't hang, even if you've yanked the network cable. I'm tempted to call that a bug in your TCP/IP stack at this point (though that seems unlikely with BSD).

The "Timeout" parameter is probably only going to affect IO::Socket methods so sysread probably won't honor it. However, looking for a "read" operation in IO::Socket and IO::Socket::INET, I was surprised to only find recv which didn't appear to honor the timeout either. Now IO::Socket does some tricky things so the timeout might be handled but in a way that wasn't obvious. So you could try using $mcserver->recv(...) instead.

Some timeouts in Socket are (or at least used to be) handled via alarm, so you could go that route. Though this could eventually cause corruption in Perl's internal state which would eventually kill a long-running process. (Though "safe Perl signals" will likely appear in the next major release of Perl, perhaps sooner.)

In the face of sysread blocking after select said it wouldn't, I might resort to having a watchdog process. You could avoind having the watchdog depend on select by having the main process, for example, append one byte to an open file each time it reads or write a packet (and truncate the file every M bytes). Then the watchdog could check the mtime or size of the file every N seconds and, if it doesn't change, kill the main process, start a new one, etc.

        - tye (but my friends call me "Tye")