atom feed9 messages in ru.sysoev.nginxRe: [PATH] support for UNIX socket in...
FromSent OnAttachments
Roberto De IorisMay 23, 2011 7:18 am.patch
Igor SysoevMay 23, 2011 9:35 am 
Roberto De IorisMay 23, 2011 10:41 am 
Roberto De IorisMay 23, 2011 10:43 am 
Igor SysoevMay 23, 2011 10:48 am 
Igor SysoevMay 23, 2011 10:51 am.zero
Roberto De IorisMay 23, 2011 11:17 am 
Igor SysoevMay 23, 2011 11:36 am 
nri.plSep 17, 2012 12:04 am 
Subject:Re: [PATH] support for UNIX socket in abstract namespace
From:Roberto De Ioris (robe@unbit.it)
Date:May 23, 2011 11:17:23 am
List:ru.sysoev.nginx

On Mon, May 23, 2011 at 07:42:02PM +0200, Roberto De Ioris wrote:

On Mon, May 23, 2011 at 04:18:30PM +0200, Roberto De Ioris wrote:

(Warning this is Linux only)

Hi all, the attached path adds support for unix socket in abstract namespace. They are special sockets without filesystem correspondence (so you can use them without thinking about permissions or in chroot). In netstat they are reported with a '@' prefix.

For example (using uWSGI):

uwsgi -s @funnysock

netstat -l

unix 2 [ ACC ] STREAM LISTENING 23813 @funnysock

After applying the patch you can connect to it with

uwsgi_pass unix:@funnysock;

I hope it can be useful

Thank you for the feature. I think it's better to allow nginx configuration parser to support "\0" as binary 0. Then this socket may be set as

uwsgi_pass unix:\0funnysock;

I fear it will require changes changes as 0 being the token delimeter in config parsing :(

Could you test the attached patch ?

This is the same code i made after you suggestion, but in the url parsing code (ngx_parse_unix_domain_url), ngx_cpystrn() is used and it takes '\0' in account.

Changing ngx_cpystrn to not use \0 fixes the problem. Probably substituting it with ngx_memcpy is the way to go.

Another thing to do is "fixing"

u->addrs[0].socklen = sizeof(struct sockaddr_un);

to

u->addrs[0].socklen = sizeof(saun->sun_family)+len;