[CalendarServer-users] Couldn't listen onany:logs/caldavd.sock: [Errno 22] Invalid argument.

[Glyph Lefkowitz]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20110611/fc79dbe9/attachment.html>