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

[Glyph Lefkowitz]

On Jun 11, 2011, at 7:30 PM, Scott Cherf wrote:

> 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

This error seemed out of place to me (bind can fail with EOPNOTSUPP, but it isn't documented to fail with ENOTSUP, which is what you're seeing), so I looked at my original C example, and realized that I dashed it off a bit too quickly.  I've attached a more scrupulously correct version, which properly uses sockaddr_un instead of guessing how things are laid out with sockaddr.



You will probably get the same behavior out of this anyway, but (A) it would be good to make sure, and (B) the corrected code may be of academic interest to you.

> [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")

Yep.

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

I think you mean "under 10.6.2"; this definitely works on other versions.  That is a reasonable interpretation, although I don't have any 10.6.2 machines to test on at the moment.  Neither should you, really; update both those machines to 10.6.7. :)

> 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.

You shouldn't be needing to malloc() sockaddrs; they all have a fixed length.  You're right that my previous example was a little bogus though, the current one should illustrate it better.

> Regards and thanks again,

No problem.  This sounded like a really juicy problem, but I guess we've come to the rather pedestrian conclusion that you should just update your server :).

One final note: in your previous message, you said:

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

That is under the maximum, but only just.  This standard reference may be of interest to you:

<http://pubs.opengroup.org/onlinepubs/009604499/basedefs/sys/un.h.html>

The size of sun_path has intentionally been left undefined. This is because different implementations use different sizes. For example, 4.3 BSD uses a size of 108, and 4.4 BSD uses a size of 104. Since most implementations originate from BSD versions, the size is typically in the range 92 to 108.

Applications should not assume a particular length for sun_path or assume that it can hold {_POSIX_PATH_MAX} characters (255).

> Scott.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20110611/27066c09/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bindit.c
Type: application/octet-stream
Size: 734 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20110611/27066c09/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20110611/27066c09/attachment-0003.html>