[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