Hi Glyph -

I had to make a few trivial changes to the code but its spirit returns the following on my development machine:

[Butte:Users/cherf/tmp] cherf% bindit some.socket
bind: Operation not supported
[Butte:Users/cherf/tmp] cherf% bindit /tmp/some.socket
[Butte:Users/cherf/tmp] cherf% uname -a
Darwin Butte.local 10.6.0 Darwin Kernel Version 10.6.0: Wed Nov 10 18:13:17 PST 2010; root:xnu-1504.9.26~3/RELEASE_I386 i386

Here it is again on the server:

[alphonse:~/tmp] cherf% bindit some.socket
bind: Invalid argument
[alphonse:~/tmp] cherf% bindit /tmp/some.socket
bind: Address already in use
[alphonse:~/tmp] cherf% rm /tmp/some.socket
[alphonse:~/tmp] cherf% bindit /tmp/some.socket
[alphonse:~/tmp] cherf% uname -a
Darwin alphonse 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

You may notice the error s different between 10.6.6 (development machine "Butte") and 10.6.2 (server "Alphonse")

I believe this implies bind will not accept a relative pathname for a unix family socket under 10.6

Please let me know if that's also your interpretation. If you'd like a complete copy of the modified test let me know. All I did really was malloc the socket address so I could stuff a variable length pathname into it.

Regards and thanks again,

Scott.

On Jun 11, 2011, at 2:53 PM, Glyph Lefkowitz wrote:


On Jun 11, 2011, at 4:22 AM, Scott Cherf wrote:

Hi Glyph -

No joy. I checked out CalendarServer 2.5 to /Volumes/Users/cherf/tmp and tried again with the following results:


Bummer; although, I am not surprised it's not that straightforward.

[alphonse:~/tmp/CalendarServer-2.5] cherf% pwd
/Users/cherf/tmp/CalendarServer-2.5
[alphonse:~/tmp/CalendarServer-2.5] cherf% python
Python 2.6.6 (r266:84292, Jun  8 2011, 18:50:17) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> skt = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
>>> skt.bind("some.socket")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in bind
socket.error: [Errno 22] Invalid argument
>>> skt.bind ("/tmp/some.socket")
>>> skt.listen(5)
>>> 

The previous pathname length was 87 characters (plus 12 for "/some.socket" = 99) which doesn't seem too long for a POSIX name. 

I noticed the python manual made a distinction between relative and absolute pathnames in bind statements, which was why I thought that was the difference. but I'm just guessing.

I might get closer if it were possible to include something that would let me test the two statements:

  skt = self.createInternetSocket()
  skt.bind (self.port) 

self.createInternetSocket is just the 'socket.socket' call, basically.  So the test you're doing is more or less already covering this.

in relative isolation but I couldn't find the createInternetSocket  method (in fact I don't know enough about python to guess what sort of object "self" is :). It still looks like some sort of python problem to me though. I noticed that unix.py makes a reference to twisted.test.test_unix. Is that test case available somewhere? Perhaps running it on my system would give me a better idea of what's happening. Failing that I'll need to spend some time learning the Python debugger.

Before trying to debug in Python, let's see if we get the same behavior out of a C program:

Compile this program:

/* cc bindit.c -o bindit */

#include <string.h>
#include <sys/socket.h>

int main(int argc, char** argv) {
    int skt;
    char* pathname = argv[1];
    skt = socket(AF_UNIX, SOCK_STREAM, 0);
    if (skt == -1) {
        perror("socket");
        return 1;
    }

    struct sockaddr addr;
    addr.sa_family = AF_UNIX;
    strcpy(addr.sa_data, pathname);

    if (bind(skt, &addr, strlen(pathname) + 1 + sizeof(addr.sa_family))) {
        perror("bind");
        return 2;
    }
    return 0;
}

and then run './bindit some.socket' and './bindit ~/some.socket' and see if the behavior differs. If it does, we can eliminate Python as a culprit.

Sorry for the delay!  I hope that this sheds some light on things.

-glyph