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
_______________________________________________
calendarserver-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
