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

[Scott Cherf]

Hi Glyph -

It's possible the juiciness factor hasn't been completely eliminated :)

I recompiled and ran the improved test under 10.6.2 and observed:

[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
[alphonse:~/tmp] cherf% cc -ggdb -o bindit bindit2.c
[alphonse:~/tmp] cherf% bindit some.socket
bind: Invalid argument
[alphonse:~/tmp] cherf% rm some.socket
[alphonse:~/tmp] cherf% bindit /Users/cherf/tmp/some.socket
bind: Invalid argument
[alphonse:~/tmp] cherf% rm /tmp/some.socket
[alphonse:~/tmp] cherf% bindit /tmp/some.socket
[alphonse:~/tmp] cherf% rm /tmp/some.socket
[alphonse:/tmp] cherf% cd /tmp
/tmp
[alphonse:/tmp] cherf% /Users/cherf/tmp/bindit some.socket
[alphonse:/tmp] cherf% 

Note that neither relative or absolute pathnames work in my home directory, but both work in the /tmp directory

then again on 10.6.6:

[Butte:~/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
[Butte:~/tmp] cherf% cc -ggdb -o bindit bindit2.c
[Butte:~/tmp] cherf% bindit some.socket
[Butte:~/tmp] cherf% rm some.socket
[Butte:~/tmp] cherf% bindit /Users/cherf/tmp/some.socket
[Butte:~/tmp] cherf% 

And now for a final, peculiar case. In this example, I've mounted my home directory from Alphonse (the 10.6.2 server) at /Volumes/Users/cherf on the 10.6.6 development machine Butte:

[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
[Butte:Users/cherf/tmp] cherf% pwd
/Volumes/Users/cherf/tmp
[Butte:Users/cherf/tmp] cherf% cc -ggdb -o bindit bindit2.c
[Butte:Users/cherf/tmp] cherf% bindit some.socket
bind: Operation not supported
[Butte:Users/cherf/tmp] cherf% bindit /Volumes/Users/cherf/tmp/some.socket
bind: Operation not supported
[Butte:Users/cherf/tmp] cherf% 

Looking at /usr/include/sys/un.h on the 10.6.2 machine, sun_path is 104 bytes long, as you mentioned. Both the /Users and /tmp directories on that machine are local volumes but the /Users directory is an external USB drive while the /tmp directory is on the internal drive.

In the second example running 10.6.6, my home directory is on the internal drive.

In the third example, running 10.6.6, my home directory is on a network mount.

So I believe the way I'll write this up on the Trac ticket is as follows:

Ticket #265 (new Defect) 

Unable to start calendar server on 10.4.10 system due to invalid argument error

Attempting to create inter-process communications sockets on filesystems hosted on external disk drives will fail with an Invalid Argument error. Attempts to create sockets on network filesystems will fail with an Operation Not Supported error. Calendar Servers must be configured to run from directories hosted by a local filesystem on an internal disk.

---------

Now that we've been through this, I notice the original ticket shows the error occurring  in the filesystem /volumes/raider, which is consistent with an external USB or Firewire drive. Although I haven't tested it, I don't believe the filesystem type is relevant in this case since both the external USB drive and the internal drive used for the 10.6.2 tests were formatted as MacOS Extended (Journaled) filesystems. I also can't know if this problem persists under 10.6,6 without connecting an external drive to my development machine. If I can dig one up I'll try it.

This ticket is currently assigned to wsanchez, shall I write up the above as a comment, attaching the test code?

Thanks again for all your help tracking this down. Later today I'll reconfigure Alphonse to run the Calendar Server from a local filesystem and report back on the results. I may be premature, but I'm thinking we've found the problem.

Regards,
Scott.


On Jun 11, 2011, at 9:55 PM, Glyph Lefkowitz wrote:

> <bindit.c>

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