Hi! At the moment I'm a bit stymified about a nonworking ZOPE :( So what exactly does this mean: Temporarily Unavailable The resource you requested is temporarily unavailable - please try again later. (102) failure during connect Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
Andreas Kostyrka wrote:
At the moment I'm a bit stymified about a nonworking ZOPE :(
So what exactly does this mean:
Temporarily Unavailable
The resource you requested is temporarily unavailable - please try again later.
(102) failure during connect
Andreas, This is the archtypical fatal error message. The pcgi-wrapper couldn't establish the connection. You may be able to use pcgifile to figure out why: http://starship.python.net/crew/jbauer/persistcgi/pcgifile/ The 102 error code is simply a way to help you quickly locate where it occurs in the C source. I used the original "Temporarily unavailable" error message for backward consistency with earlier pcgi version. Since I know you're a skilled C programmer with vast knowledge about http & sockets, I won't spend too much time assisting you. Remember that last statement next time I need help from you <wink>. Seriously, you may find it easiest to put in some debug code into pcgi-wrapper and recompile it if pcgifile.py doesn't help. "temporary"-is-however-long-it-takes-for-Andreas-to-fix-it-ly yr's Jeff Bauer Rubicon Research
On Fri, 20 Aug 1999, Jeff Bauer wrote:
Andreas Kostyrka wrote:
At the moment I'm a bit stymified about a nonworking ZOPE :(
So what exactly does this mean:
Temporarily Unavailable
The resource you requested is temporarily unavailable - please try again later.
(102) failure during connect
Andreas,
This is the archtypical fatal error message. The pcgi-wrapper couldn't establish the connection. You may be able to use pcgifile to figure out why:
http://starship.python.net/crew/jbauer/persistcgi/pcgifile/ Well, I didn't discover my problem, but I've discovered a ``bug'' in pcgifile.py: It doesn't like Zope/__init__.py:
if os.path.isfile(p) or os.path.isfile(p+"/__init__.py"): self.resource.append("Module:\t%s" % p) else: self.log.append("module not found: %s" % p) raise PcgiFileException
The 102 error code is simply a way to help you quickly locate where it occurs in the C source. I used the
Well, that much I've discovered myself ;)
original "Temporarily unavailable" error message for backward consistency with earlier pcgi version. Since I know you're a skilled C programmer with vast knowledge about http & sockets, I won't spend too much time assisting you. Remember that last statement next time I need help from you <wink>. Seriously, you may find Well, somehow, my sarcasm detector went crazy at this place ;) (Question: Was this an opaque reference to some earlier crime of mine, that I've already purged from memory, or was it just a general remark?)
it easiest to put in some debug code into pcgi-wrapper and recompile it if pcgifile.py doesn't help. Ok, seems like this is a remark I often give myself: I can't debug via phone, nor via email, very well :(
"temporary"-is-however-long-it-takes-for-Andreas-to-fix-it-ly yr's
Jeff Bauer Rubicon Research
-- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
Andreas Kostyrka wrote:
I know you're a skilled C programmer with vast knowledge about http & sockets. I won't spend too much time assisting you. Remember that last statement next time I need help from you <wink>. Seriously, you may find
Well, somehow, my sarcasm detector went crazy at this place ;) (Question: Was this an opaque reference to some earlier crime of mine, that I've already purged from memory, or was it just a general remark?)
No Andreas, you've been very helpful to the Zope community at large. It was just a weak attempt at humor, conveying the difficulty of remotely debugging your problem. I just meant (in jest) that you could save that portion of my message to throw back in my face the next time I needed your help with virtual hosting or related topics. Brian provided the 2 most common reasons for your error to occur. The error is aggravating, but shouldn't be too difficult for you to track down. Once you've determined it, if you think of a better way we can report it to the user, please pass on a suggestion to Brian or me. Jeff Bauer Rubicon Research
On Fri, 20 Aug 1999, Jeff Bauer wrote:
No Andreas, you've been very helpful to the Zope community at large. It was just a weak attempt at humor, conveying the difficulty of remotely debugging your problem. I just meant (in jest) that you could save that portion of my message to throw back in my face the next time I needed your help with virtual hosting or related topics. Well, to be frank, debugging Apache configuration stuff per Email is not that much fun. Well, one tries :) And no, you couldn't probably have found my problem here, at least not without shell access. :(
Brian provided the 2 most common reasons for your error to occur. The error is aggravating, but shouldn't be too difficult for you to track down. Once you've determined it, if you think of a better way we can report it to the user, please pass on a suggestion to Brian or me. Well, I don't know if this the general cause for this, but see my other post: pcgi as of Z2.0b4 seems to have a bug on multiple python systems where the ZOPE Python is not the first to be found in PATH.
Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
On Fri, 20 Aug 1999, Jeff Bauer wrote: Well, I've learned something new about python, pcgi and the world ;) Question: Any arguments why you are doing this: int pcgiStartProc(pcgiResource *r) { pid_t pid; char *p = NULL; int i = 0; UNION_SEMUN arg; arg.val=0; if ((p=strrchr(r->sw_exe, PATHSEP))==NULL) { p = r->sw_exe; } else { p++; } I've discovered my problem being the following: [pid 1792] execve("/opt/mtg/bin/python", ["python", "/opt/mtg/Z/ZOPE-2.0.0b4/pcgi/pcg"...], [/* 36 vars */]) = 0 Which further down, lead the python in /opt/mtg to find /usr as it's prefix. Basically, I've got here a standard RH6.0 linux system, and being nice, I this time decided to let the standard 1.5.1 python be, and compiled my own 1.5.2 in a seperate path. Well, for most things the standard python that comes with tkinter, etc. is the right one, so /usr/bin/python is in the PATH. Now python is execed without the pathinfo, so it does have to search for itself along the PATH :( Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
Andreas Kostyrka wrote:
Basically, I've got here a standard RH6.0 linux system, and being nice, I this time decided to let the standard 1.5.1 python be, and compiled my own 1.5.2 in a seperate path.
Does your pcgi info file (Zope.cgi) specify a PCGI_EXE directive that points to your new python 1.5.2 path? -Jeff
On Fri, 20 Aug 1999, Jeff Bauer wrote:
Andreas Kostyrka wrote:
Basically, I've got here a standard RH6.0 linux system, and being nice, I this time decided to let the standard 1.5.1 python be, and compiled my own 1.5.2 in a seperate path.
Does your pcgi info file (Zope.cgi) specify a PCGI_EXE directive that points to your new python 1.5.2 path? Yes it does: #!/opt/mtg/Z/ZOPE-2.0.0b4/pcgi/pcgi-wrapper PCGI_NAME=Zope PCGI_MODULE_PATH=/opt/mtg/Z/ZOPE-2.0.0b4/lib/python/Zope PCGI_PUBLISHER=/opt/mtg/Z/ZOPE-2.0.0b4/pcgi/pcgi_publisher.py PCGI_EXE=/opt/mtg/bin/python PCGI_SOCKET_FILE=/misc/home/mtg/mtgzope/var/pcgi.soc PCGI_PID_FILE=/misc/home/mtg/mtgzope/var/pcgi.pid PCGI_ERROR_LOG=/misc/home/mtg/mtgzope/var/pcgi.log PCGI_DISPLAY_ERRORS=1 BOBO_REALM=Zope BOBO_DEBUG_MODE=1 STUPID_LOG_FILE=/tmp/debug.log INSTANCE_HOME=/misc/home/mtg/mtgzope SOFTWARE_HOME=/opt/mtg/Z/ZOPE-2.0.0b4/lib/python
The problem is cleanly visible in the sourcecode: /*pseudo python translation*/ exec(PCGI_EXE,string.split(PCGI_EXE,"/")[-1],...) If this makes sense is questionable, and it's an bug if the python in PCGI_EXE is not the first python on PATH. Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
Andreas Kostyrka wrote:
If this makes sense is questionable, and it's an bug if the python in PCGI_EXE is not the first python on PATH.
It's definitely a bug. Probably related to Principia legacy(?) Does removing the lines below make everything work okay? if ((p=strrchr(r->sw_exe, PATHSEP))==NULL) { p = r->sw_exe; } else { p++; } I think it's now safe to assume that PCGI_EXE is part of the Zope landscape -- which wasn't true when pcgi-wrapper was initially supporting pre-Zope systems. (It was still a bug, but apparently nobody stumbled over it.) If it's okay with Brian, we'll just excise those lines of code. -Jeff
On Fri, 20 Aug 1999, Jeff Bauer wrote:
Andreas Kostyrka wrote:
If this makes sense is questionable, and it's an bug if the python in PCGI_EXE is not the first python on PATH.
It's definitely a bug. Probably related to Principia legacy(?) Does removing the lines below make everything work okay?
if ((p=strrchr(r->sw_exe, PATHSEP))==NULL) { p = r->sw_exe; } else { p++; } Well, actually, I just replaced the second parameter of the exec from "p" to "r->sw_exe". It just started to work magically :)
Andreas -- Andreas Kostyrka | andreas@mtg.co.at phone: +43/1/7070750 | phone: +43/676/4091256 MTG Handelsges.m.b.H. | fax: +43/1/7065299 Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
participants (2)
-
Andreas Kostyrka -
Jeff Bauer