Dear List, since two days I am now banging my head against a seemingly simple Zope setup which just does not want to work. I need to install a Zope server with to instances running against the same object database via ZEO. This same setup is working flawlessly in our development environment. To make a clean install, I started from scratch and downloaded Zope-2.6.2b2 (the full Linux binary version) and ZEO-2.0.1b1. I set up ZEO to run from the Zope-2.6.2-Diretory and creatade a new Directory for the first Zope instance. Starting the instance without ZEO works flawlessly, a new Data.fs is created in INSTANCE_HOME/var. Starting ZEO also does not produce any errors neither on the console nor in the ZEO_EVENTS.log and a new Data.fs is created in ZOPE_HOME/var, where ZEO is running. Now, when I install the custom_zodb.py into the INSTANCE_HOME, the Zope server still comes up against ZEO. I can watch the Data.fs in ZOPE_HOME grow as the initial objects are created. But the first request (whatever it is, e.g. http://localhost or http://localhost/manage) blocks indefinitely. According to top, Zope is idling along and doing nothing and according to ethereal, the request does not trigger *any* traffic to the ZEO server and no response is sent back to the web-browser. I tried to find the place, where the systems is blocking but got nowhere. I used sys.settrace to trace all function calls only to find, the sys.settrace is thread specific ;-/ no dice. I am now utterly helpless and have no idea how to go on. Hopefully someone on this mailing-list can shed a light on this problem. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
I know, you should not followup to your own message, but I wanted to give some additional information I just found. Trying to pinpoint the place, where the System is blocking, I inserted sys.stderr.write commands all over the ZServer/meduse code. By patching ZServer.PubCore.ZRendezvous.ZRendezvous.__init__ and ZServer.PubCore.ZServerPublisher.ZServerPublisher.__init__ I found, that the last method is *never* executed, when I run with ZEO. I really don't understand that. ZRendezous just creates a bunch of threads all running the ZServerPublisher.__init__ function. I cannot find *any* reason, why the threads should refrain from running ... just because ZEO is used ??? This sounds really weird in my ears, but maybe someone with a better brain than mine can help out ? Stefan. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
Again following up to my own posting ... New information: I found the real Problem. Now I would like an explanation and a workaround ... To recapitulate: I have to Zope setups, our development setup, which is working and a new setup which fails. Both use the same Zope and ZEO version. There is one notable difference: The development setup is running on port 8080, the new setup must run on port 80. Therefore, our development setup is started as user zope (using su) whereas the new setup is started as user root with the -u zope options. I know, I should put a proxy before Zope, but this new setup is for in-house use only, and therefore I thought the proxy not to be necessary. The Moment I start the new setup on port 8080 with su, the ZEO connection starts working !! What the heck ... I really cannot fathom the reason for the observer behavior: o started as root with -u zope and no ZEO: working o started as zope with su and no ZEO: working o started as zope with su and ZEO: working o started as root with -u zope and ZEO: *NOT* working And to reiterate: Not working means, that python just wont start the additional service threads: start_new_thread is called successfully in ../ZRendezvous.py but the new thread never starts executing the code from ../ZServerPublisher.py. So: I think I'll have to delve into pound as proxy, but I really would like an explanation for this behavior ... I don't get it ... Very baffled and curious, Stefan. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
On Thu, Jun 19, 2003 at 09:57:56AM +0200, Stefan Bund wrote:
There is one notable difference: The development setup is running on port 8080, the new setup must run on port 80. Therefore, our development setup is started as user zope (using su) whereas the new setup is started as user root with the -u zope options.
aha. i've recently had problems there too.
I really cannot fathom the reason for the observer behavior:
(snip)
o started as zope with su and ZEO: working
o started as root with -u zope and ZEO: *NOT* working
this is exactly the behavior i observe too, with zope 2.6.1. I think -u is broken.
And to reiterate: Not working means, that python just wont start the additional service threads: start_new_thread is called successfully in ../ZRendezvous.py but the new thread never starts executing the code from ../ZServerPublisher.py.
I didn't trace it that far, but I think we're seeing the same behavior. I did notice that when starting with -u zope and ZEO, zope gets as far as to log the startup messages including the server ports, and then it appears to never finish responding to any requests. i tried connecting via ftp and i get the server ID message (medusa experimental blah blah), but i can't ever get a directory listing. I tried a few straces and there did seem to be some threading weirdness going on.
So: I think I'll have to delve into pound as proxy, but I really would like an explanation for this behavior ... I don't get it ...
another alternative, which we used as a workaround on linux: use iptables to do port forwarding. This doesn't work for local requests (e.g. http://localhost:80 will fail), it only forwards requests from other hosts. we're successfully using iptables to make ftp connections to zope on port 21. Now we can use privileged ports without starting zope as root. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's TWINKLY-STINKY SILLIPHONT SPRAY CAN! (random hero from isometric.spaceninja.com)
Paul Winkler <pw_lists@slinkp.com> writes: [...]
this is exactly the behavior i observe too, with zope 2.6.1. I think -u is broken.
Thank you... it is comforting to see that I have not lost my mind :-)
And to reiterate: Not working means, that python just wont start the additional service threads: start_new_thread is called successfully in ../ZRendezvous.py but the new thread never starts executing the code from ../ZServerPublisher.py.
I didn't trace it that far, but I think we're seeing the same behavior. I did notice that when starting with -u zope [...] I tried a few straces and there did seem to be some threading weirdness going on.
Yes, it s really weird... I just can t find any connection between the threading issues and the usage of ZEO. Hmpf. I hope, some python god will delve into this to find a solution. It feels a bit awkward, that a bug like this is sleeping there. And I personally don t find it very comforting to know, it will hopefully only happen with -u... to feel sure I d like to know a little bit more.
another alternative, which we used as a workaround on linux: use iptables to do port forwarding. [...]
I thought of that too, but 1. there's this localhost problem and 2. pound is easy to install and filters requests, so it makes the setup more secure ... even though on this in-house site thats not so very important I have it running now but that has cost me some sleepless nights... Stefan. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
Stefan Bund wrote at 2003-6-18 15:19 +0200:
... To make a clean install, I started from scratch and downloaded Zope-2.6.2b2 (the full Linux binary version) and ZEO-2.0.1b1.
Zope-2.6.2 comes with ZEO-1. ZEO-1 is incompatible with ZEO-2. Replace Zope's "ZEO" package (--> "lib/python/ZEO") with that coming with ZEO2 and try again. Dieter
Dieter Maurer <dieter@handshake.de> writes:
Stefan Bund wrote at 2003-6-18 15:19 +0200:
... To make a clean install, I started from scratch and downloaded Zope-2.6.2b2 (the full Linux binary version) and ZEO-2.0.1b1.
Zope-2.6.2 comes with ZEO-1. ZEO-1 is incompatible with ZEO-2.
I did that. To be more precise, I deleted any ZEO directory i could find (I dont remember doing that, but find does not find any) and symlinked the ZEO directory from the ZEO distribution into the lib/python2.1/site-packages directory. Thats the exact same setup running on our own server. so... some additional information: I already stated, that *no* network trafik to the ZEO server is generated on any request, that even the service threads don't seem to start. This is supplemented by the STUPID_LOG_FILE where I only find: U 000000000 2003-06-18T21:16:50 System startup B 144708644 2003-06-18T21:17:11 GET / I 144708644 2003-06-18T21:17:11 0 I just now tried to use the Standalone ZODB3.2 distribution to no avail. The phenomenon is exacly the same as above... I sincerely hope for some additional information, Thanks, Stefan. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
Stefan Bund wrote at 2003-6-18 21:31 +0200:
... This is supplemented by the STUPID_LOG_FILE where I only find:
U 000000000 2003-06-18T21:16:50 System startup B 144708644 2003-06-18T21:17:11 GET / I 144708644 2003-06-18T21:17:11 0
This information usually is not in the "STUPID_LOG_FILE" but in the "-M" logfile. Are you running RedHat 9? It has bugs in its "pthreads" library. Dieter
Dieter Maurer <dieter@handshake.de> writes:
Stefan Bund wrote at 2003-6-18 21:31 +0200:
U 000000000 2003-06-18T21:16:50 System startup B 144708644 2003-06-18T21:17:11 GET / I 144708644 2003-06-18T21:17:11 0
This information usually is not in the "STUPID_LOG_FILE" but in the "-M" logfile.
Grmpf... of course, my mistake :-)
Are you running RedHat 9? It has bugs in its "pthreads" library.
No. I'm running debian woody. -- Stefan Bund, Dipl.Phys. a r T e c _____ Entwicklung, Administration visual solutions / | /| |----/_| sbund@artec-berlin.com | / | / Fon: 030 / 884684-0 | Fax: 030 / 884684-15 |/___|/ Gottfried-von-Cramm-Weg 35-37 | Berlin | 14193 | http://www.artec-berlin.com
participants (3)
-
Dieter Maurer -
Paul Winkler -
Stefan Bund