openresty / lua-resty-redis

Lua redis client driver for the ngx_lua based on the cosocket API
1.91k stars 448 forks source link

Unix file socket not working #75

Open leetrout opened 8 years ago

leetrout commented 8 years ago

I'm having trouble with red:connect("unix:/tmp/redis.sock"). It does not appear to be working.

Full code snippet

local ok, err = red:connect("unix:/tmp/redis.sock")
if not ok then
    ngx.log(ngx.ERR, "failed to connect to redis: ", err)
    ngx.print("no redis")
    return
end

In the error log

2016/01/28 13:55:53 [crit] 30531#0: *1 connect() to unix:/tmp/redis.sock failed (2: No such file or directory), client: 10.0.2.2, server: _, request: "POST /lee/models/HelloWorld/ HTTP/1.1", host: "127.0.0.1:12080"

and the socket file itself does exist and is 0777

[root@localhost ~]# stat /tmp/redis.sock
  File: ‘/tmp/redis.sock’
  Size: 0           Blocks: 0          IO Block: 4096   socket
Device: fd01h/64769d    Inode: 263869      Links: 1
Access: (0777/srwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:user_tmp_t:s0
Access: 2016-01-28 13:54:54.289000000 -0500
Modify: 2016-01-28 13:54:54.289000000 -0500
Change: 2016-01-28 13:54:54.289000000 -0500
 Birth: -
agentzh commented 8 years ago

@leetrout This is strange. Maybe you have invisible characters in your connect string? I've just tried the following minimal and standalone example on my side with the latest OpenResty:

location = /t {
    content_by_lua_block {
        local redis = require "resty.redis"
        local red = redis:new()

        local ok, err = red:connect("unix:/tmp/redis.sock")
        if not ok then
            ngx.say("failed to connect: ", err)
            return
        end

        ok, err = red:set("dog", "an animal")
        if not ok then
            ngx.say("failed to set dog: ", err)
            return
        end

        ngx.say("set result: ", ok)
    }
}

Accessing /t gives

set result: OK

And in my redis.conf file, I have

unixsocket /tmp/redis.sock
unixsocketperm 777

Maybe you can try this out on your side? Also, please ensure you are running the latest OpenResty to avoid running into ancient bugs.

leetrout commented 8 years ago

Running 1.9.7.2 I pasted in your location block

curl "http://127.0.0.1:12080/t"
failed to connect: no such file or directory

in the logs

2016/01/28 14:50:36 [crit] 29619#0: *3 connect() to unix:/tmp/redis.sock failed (2: No such file or directory), client: 10.0.2.2, server: _, request: "GET /t HTTP/1.1", host: "127.0.0.1:12080"

and to confirm with redis cli

[vagrant@localhost ~]$ redis-cli -s /tmp/redis.sock
redis /tmp/redis.sock> keys *
(empty list or set)
redis /tmp/redis.sock> set foo bar
OK
redis /tmp/redis.sock> get foo
"bar"
redis /tmp/redis.sock>

I'll go double check file permissions and such but it seems odd. This is centos 7 on vagrant.

agentzh commented 8 years ago

@leetrout Yeah, it's weird. Maybe some misconfigurations or other mistakes.

leerob727 commented 8 years ago

( firstly, thanks so much to agentzh for openresty and being so active in responding to everyone's cries for help across the web... your answers have helped me numerous times already )

For future googlers (this may only apply to Fedora/Centos/RedHat systems: I came to this via googling "openresty unix socket (2: No such file or directory)" and found the solution finally by searching "nginx unix socket no such file or directory"): please reference https://serverfault.com/questions/463993/nginx-unix-domain-socket-error/464025#464025

[ excerpt ] You can't place sockets intended for interprocess communication in /tmp. For security reasons, recent versions of Fedora use namespaced temporary directories, meaning every service sees a completely different /tmp and can only see its own files in that directory. To resolve the issue, place the socket in a different directory, such as /run (formerly known as /var/run). ( but /run is not writable directly, you can instruct systemd to create a directory under it which is writable by both processes )

agentzh commented 8 years ago

@leetrout Thanks for the note. Appreciated.