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

Scott Cherf cherf at ambient-light.com
Sat Jun 11 19:30:52 PDT 2011


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
> 

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


More information about the calendarserver-users mailing list