Re: [CalendarServer-users] Couldn't listen on any:logs/caldavd.sock: [Errno 22] Invalid argument.
For the list. Sorry about dropping the CC. ---- Hi Glyph - Well I re-installed python, this time version 2.7. I installed once from MacPorts and once using the .dmg distribution from python.org. Unfortunately neither install corrected the problem. Later I read the README file and discovered Twisted isn't supposed to work with Python 2.7 so I re-installed 2.6 from MacPorts. I couldn't find a 2.6 distribution on the python.org site but I didn't really look hard either. Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following: [alphonse:tags/release/Twisted] 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
I've also attached an rtf containing the results of performing a 'run -v' from the CalanderServer 2.5 directory right after re-installing python 2.6. I didn't use run -s before I did it so it shows a stripped down list of warnings, I thought some of them might be pertinent. Not being familiar with python (or Twisted) I'm at a loss. I can say that AFAIK the python 2.6 install is vanilla. I'm a Perl/Objective C guy and I've only started to become acquainted with python as a result of putting up MOD_PYTHON for Trac in Apache. Any clues or suggestions appreciated and I'll just keep banging my head in private otherwise... "three man teams, radio silence, weapons-free rules of engagement"? Indeed! :) Regards, Scott. On Jun 7, 2011, at 7:29 PM, Glyph Lefkowitz wrote:
On Jun 7, 2011, at 6:22 PM, Scott Cherf wrote:
On Jun 7, 2011, at 5:58 PM, Glyph Lefkowitz wrote:
On Jun 7, 2011, at 5:52 PM, Scott Cherf wrote:
On Jun 7, 2011, at 3:29 PM, Glyph Lefkowitz wrote:
Clearly this release tag should work, but I'm curious: can you reproduce this behavior on trunk, or does trunk start up correctly for you?
-glyph
Yes I can reproduce it on the trunk using the top of tree as of earlier today. It must be some type shared configuration problem.
Are there any other salient details about your configuration?
Here's a high level view of the machine
System Software Overview:
System Version: Mac OS X 10.6.2 (10C540)
Not that this should make a difference, but: you said 10.6.6 earlier, but this says 10.6.2.
Kernel Version: Darwin 10.2.0 Boot Volume: Alphonse Boot Mode: Normal Computer Name: Alphonse User Name: Scott Cherf (cherf) Secure Virtual Memory: Not Enabled 64-bit Kernel and Extensions: No Time since boot: 14:33
I'm running Python 2.6 along with a complicated and somewhat handcrafted collection of open source software installed in /opt/local. It would be difficult to characterize all of the versions of utilities installed though I'm happy to answer questions.
The only interesting software would be dependencies of calendar server. Do you have a custom version of Twisted? Of Python?
Where are you checking out the code?
The full paths to the checked out versions are:
/Users/cherf/Projects/Source/MacOSForge/CalendarServer/trunk /Users/cherf/Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5
Both were checked out this morning using Xcode 3 from:
http://svn.macosforge.org/repository/calendarserver
Have you modified anything, either configuration or code?
In both examples I performed the recommended copy caldavd-test.plist, which was done by the script on trunk and manually on 2.5. I'm not aware of making any other changes.
Good to know.
Do other machines experience the same error?
I haven't built on any other machines yet since I only have a production environment on this one.
If it also affects trunk, that is good news - it narrows it down a bit, since it must be in code that's common between the two.
Fire away with any questions you can think of,
What does this Python program do on your system?
import socket skt = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) skt.bind("some.socket") skt.listen(5)
Does it behave differently inside the directory you mentioned? A few directories down? (In case you're not familiar with socket programming, it should just create a file called 'some.socket', which you can safely remove.)
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________ Cellent Finance Solutions AG Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
John - Thanks, I was thinking the same thing myself and was reading that page when I received your mail. Glyph had a simple test to see if my installation of python was working correctly. The actual line that's reporting the error is in the file unix.py, which shows up in the Twisted/twisted/internet/unix.py file at line 89 and reads: skt.bind(self.port) I'm not sure what self.port resolves to. Regards, Scott. On Jun 8, 2011, at 10:35 PM, Holland, John wrote:
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________
Cellent Finance Solutions AG
Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
I assure you I'm using Python's bind correctly - this isn't my first rodeo :-). self.port resolves to the path name, in that code. The test program I wrote worked on my system as I expected it to. Regarding the documentation you're referring to: the documentation on that page says "The format of address depends on the address family — see above". Scanning back up the page, it says "Socket addresses are represented as follows: A single string is used for the AF_UNIX address family.". The type of socket here is indeed an AF_UNIX socket, and the address is its path name. Anyway, this is starting to get pretty far off topic for calendar server: basically, in this case, there's something wrong with the underlying platform; either Python or the kernel or some library that a build of Python depends on. For some reason, one of these components can't open a UNIX socket. Once that's addressed (whatever the problem is) the server should work fine. On Jun 8, 2011, at 11:05 PM, Scott Cherf wrote:
John -
Thanks, I was thinking the same thing myself and was reading that page when I received your mail.
Glyph had a simple test to see if my installation of python was working correctly. The actual line that's reporting the error is in the file unix.py, which shows up in the Twisted/twisted/internet/unix.py file at line 89 and reads:
skt.bind(self.port)
I'm not sure what self.port resolves to.
Regards, Scott.
On Jun 8, 2011, at 10:35 PM, Holland, John wrote:
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________
Cellent Finance Solutions AG
Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
On Jun 8, 2011, at 11:50 PM, Glyph Lefkowitz wrote:
I assure you I'm using Python's bind correctly - this isn't my first rodeo :-).
No intent on my part to suggest otherwise, though having said that I've always made a practice of working from the ground up leaving no stone unturned. I know less than diddly-squat about python, I consider this an educational adventure so I started reading the book on the same page John suggested. It was pure serendipity, I had literally started reading the page about 10 minutes before he sent the message. My best regards to the both of you, :)
Hello John - Forgive my doubts, as you mention I had best read the manual. You are correct, I was using python's bind incorrectly, the correct code fragment is shown below: [alphonse:~] cherf% cd Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5/ /Users/cherf/Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5 [alphonse:tags/release/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 ("/tmp/some.socket") skt.listen(5)
In fact, this works just fine on both my development machine and the server I'm trying to install the iCal server on, the difficulty was in the use of a relative pathname rather than an absolute name. Using a relative path on macOS apparently does not work, however changing the fragment to an absolute name works fine. Unfortunately this leaves me wrestling with the original problem, which is to understand why I'm seeing the error from Twisted. Again, thanks for the suggestion, Scott. On Jun 8, 2011, at 10:35 PM, Holland, John wrote:
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________
Cellent Finance Solutions AG
Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
Hi Scott, Relative paths work fine, too. However, I think the length of the full absolute path may be an issue in some cases, even if you pass it as a short relative path. If you try creating a relative-path socket in a shorter path, like your home directory, it should work. Try putting your CalendarServer checkout somewhere with a very short path, like /dccs/ instead of ~/Projects/Blah/Blah/Blah/. I'd be interested to know if that fixes it. I actually remember fixing a bug in this area a while ago: it's probably fixed on the 3.x line but not 2.x. Thanks and good luck, -glyph On Jun 10, 2011, at 6:03 PM, Scott Cherf wrote:
Hello John -
Forgive my doubts, as you mention I had best read the manual.
You are correct, I was using python's bind incorrectly, the correct code fragment is shown below:
[alphonse:~] cherf% cd Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5/ /Users/cherf/Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5 [alphonse:tags/release/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 ("/tmp/some.socket") skt.listen(5)
In fact, this works just fine on both my development machine and the server I'm trying to install the iCal server on, the difficulty was in the use of a relative pathname rather than an absolute name. Using a relative path on macOS apparently does not work, however changing the fragment to an absolute name works fine.
Unfortunately this leaves me wrestling with the original problem, which is to understand why I'm seeing the error from Twisted.
Again, thanks for the suggestion,
Scott.
On Jun 8, 2011, at 10:35 PM, Holland, John wrote:
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________
Cellent Finance Solutions AG
Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
Hi Glyph - No joy. I checked out CalendarServer 2.5 to /Volumes/Users/cherf/tmp and tried again with the following results: [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) 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. Regards, Scott. On Jun 10, 2011, at 9:35 PM, Glyph Lefkowitz wrote:
Hi Scott,
Relative paths work fine, too. However, I think the length of the full absolute path may be an issue in some cases, even if you pass it as a short relative path. If you try creating a relative-path socket in a shorter path, like your home directory, it should work.
Try putting your CalendarServer checkout somewhere with a very short path, like /dccs/ instead of ~/Projects/Blah/Blah/Blah/. I'd be interested to know if that fixes it. I actually remember fixing a bug in this area a while ago: it's probably fixed on the 3.x line but not 2.x.
Thanks and good luck,
-glyph
On Jun 10, 2011, at 6:03 PM, Scott Cherf wrote:
Hello John -
Forgive my doubts, as you mention I had best read the manual.
You are correct, I was using python's bind incorrectly, the correct code fragment is shown below:
[alphonse:~] cherf% cd Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5/ /Users/cherf/Projects/Source/MacOSForge/CalendarServer/tags/release/CalendarServer-2.5 [alphonse:tags/release/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 ("/tmp/some.socket") skt.listen(5)
In fact, this works just fine on both my development machine and the server I'm trying to install the iCal server on, the difficulty was in the use of a relative pathname rather than an absolute name. Using a relative path on macOS apparently does not work, however changing the fragment to an absolute name works fine.
Unfortunately this leaves me wrestling with the original problem, which is to understand why I'm seeing the error from Twisted.
Again, thanks for the suggestion,
Scott.
On Jun 8, 2011, at 10:35 PM, Holland, John wrote:
On 09.06.2011, at 07:25, "Scott Cherf" <cherf@ambient-light.com> wrote:
Using the fresh python 2.6 installed at /opt/local/bin/python I observed the following:
[alphonse:tags/release/Twisted] 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 >
I believe your using pythons bind incorrectly. Have a look at http://docs.python.org/release/2.6.6/library/socket.html ___________________________________
Cellent Finance Solutions AG
Firmensitz: Calwer Straße 33, 70173 Stuttgart Registergericht: Amtsgericht Stuttgart, HRB 720743 Vorstand: Thomas Wild Vorsitzender des Aufsichtsrats: Rudolf Zipf
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
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
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
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.
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>
Hi Glyph - Just writing to confirm that installing the server in a directory under the root filesystem (in this case /Users/iCal/Server/CalendarServer-2.5) works just fine, so the problem was putting it on an external USB drive. Strange, but true :) Regards, Scott.
On Jun 12, 2011, at 12:32 PM, Scott Cherf wrote:
Hi Glyph -
Just writing to confirm that installing the server in a directory under the root filesystem (in this case /Users/iCal/Server/CalendarServer-2.5) works just fine, so the problem was putting it on an external USB drive. Strange, but true :)
Hi Scott, Thanks for following this all the way to its conclusion. I'm not sure there's much we can do about it (especially given that 3.x already has a workaround for this issue; implemented for other reasons, but it will also apply to this), but it will be good to have a record of this if future users have the same problem. -glyph
Hey GLYPH - Even though the problem is fixed on 3.x I certainly appreciate the time you spent helping me get 2.5 working (it's working quite well BTW, I have it installed on two clients now and I've migrated several calendars to the server). I did make an attempt to get 3.x working earlier but couldn't and at this point I can't say exactly why because the experience has blurred together with the 2.5 adventure and I can't remember what happened where. I will try again. Best wishes to you and your project. This is a great help to me. In another life I run a small B&B in Northern California and my wife and I have constant collisions because we've never been able to share calendars before. You've made a significant contribution to improving domestic bliss :) If you accept bitcoin I'd buy you a beer or something. Best Regards, Scott. On Jun 12, 2011, at 5:59 PM, Glyph Lefkowitz wrote:
On Jun 12, 2011, at 12:32 PM, Scott Cherf wrote:
Hi Glyph -
Just writing to confirm that installing the server in a directory under the root filesystem (in this case /Users/iCal/Server/CalendarServer-2.5) works just fine, so the problem was putting it on an external USB drive. Strange, but true :)
Hi Scott,
Thanks for following this all the way to its conclusion. I'm not sure there's much we can do about it (especially given that 3.x already has a workaround for this issue; implemented for other reasons, but it will also apply to this), but it will be good to have a record of this if future users have the same problem.
-glyph
Hey GLYPH - Oops. Sorry, hadn't noticed I hit the caps lock key there....
participants (3)
-
Glyph Lefkowitz
-
Holland, John
-
Scott Cherf