No exceptions on communication errors with UNIX domain sockets #253

Open
tritondigital opened this Issue Sep 24, 2012 · 12 comments

3 participants

@tritondigital

When using UNIX domain sockets, I am not getting exceptions when there are communications errors. I see in the Redis server logs that the client is trying to connect, but the connection closes immediately. The PHP script is not receiving any indication that there is an error.

@tritondigital

Has anyone looked at this? This is a serious production issue on our side.

I could look at it myself, but I'm wondering, is the communications different between UNIX domain sockets versus TCP sockets? When we have a communications issue on TCP, it throws an exception properly. Is there anything I should look for in the code?

@michael-grunder
phpredis member

I can replicate this. I will take a look this afternoon :)

@bbroerman30

Thanks!

@tritondigital

So, any luck figuring this out?

@michael-grunder
phpredis member

I took a quick look at it, but could you let me know more specifically what you mean by connection errors? The reason I ask is that if you do this with phpredis:

$r = new Redis();
$r->connect($host, $port);

And it can't connect, you will generally just get a false return from phpredis::connect

The only time phpredis throws exceptions is when there is an invalid response from Redis or a network error after the connection is made. Are you seeing a difference in the behavior of unix sockets vs. connecting with a host/port once you have already connected?

You can certainly check the response of connect and throw your own exception.

Sorry for the delayed response, but I'm actually out of town right now. That being said, I'll be checking github :)

Cheers,
Mike

@tritondigital
@tritondigital

Hi,

Just wondering if you've had any luck reproducting the issue. I'll be on vacation all of next week, and was thinking of looking at it if you haven't already...

Thanks,
Brad

@michael-grunder
phpredis member

Hey there,

I am actually back from vacation so I will take a look this week. You are welcome to look as well and all help is appreciated! :)

@michael-grunder
phpredis member

I have done a bit of testing, but I actually do get connection errors even when running against a unix socket.

This script for example:

<?php
$r = new Redis();
$r->connect('/tmp/redis.sock');

while(true) {
    echo "Key: " . $r->get('some_key') . "\n";
    sleep(1);
}
?>

Returns false from connect if there is nothing on that Unix socket, and then throws this when it gets to the get call:

php usocket.php
PHP Fatal error:  Uncaught exception 'RedisException' with message 'Redis server went away' in /home/mike/dev/usocket.php:6
Stack trace:
#0 /home/mike/dev/usocket.php(6): Redis->get('some_key')
#1 {main}
  thrown in /home/mike/dev/usocket.php on line 6

If, on the other hand, I start the redis instance listening on /tmp/redis.sock and stop it while the script is running, it throws this exception:

PHP Fatal error:  Uncaught exception 'RedisException' with message 'read error on connection' in /home/mike/dev/usocket.php:6
Stack trace:
#0 /home/mike/dev/usocket.php(6): Redis->get('some_key')
#1 {main}
  thrown in /home/mike/dev/usocket.php on line 6

So from where I'm sitting, it looks like you should get connection errors if using a Unix socket or not. Perhaps this is a more specific type of error that is occurring which we can try to track down?

Happy to help in any way I can :)

Cheers,
Mike

@tritondigital
@bbroerman30

Just ran a bunch of test with my install. One thing I have noticed, and I'm not sure if it's due to issues with the loopback device, but if I have a connection to a server, and I bring the lo device down, the clients hang. Now, if I kill the server (even a kill-9) it drops the connections properly, and the client terminates... but if I do an ifconfig lo down, they hang... and it takes about 15 - 20 seconds after I bring it back up before they start communicating again...

I think I'll set up an example across different machines, and pull the network cable and see what happens there :)

@bbroerman30

Actually, it looks like an issue with an SSL connection, (using ssl: in the connect host string) and it doesn't happen with straight tcp socket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment