Finding crash information
I'm having a serious problem with my Zope server running in production. Platform: RedHat Linux 6 (2.2.12-20 kernel) Python 1.5.2 Zope 2.1.4 starting with: python z2.py as root/nobody on port 80 straight ZServer Under load (not too heavy, but busy) the Zope process SILENTLY stops. I get no traceback info anywhere that I can see. Nothing to stdout/stderr, nothing in Z2.log. If I start as: python z2.py -Z '' to prevent the fork and detach I still get no message when the crash occurs. I can't run this in DEBUG mode because I'm using GUF cookie mode to authenticate and the login screen ends up showing an exception error (by design?) If anyone can tell me how to run in DEBUG mode but make GUF still hide the exception error that would be a big help. If anyone can help me keep this server from crashing every forty-five minutes I'll buy 'em a beer next time they're in Portland. -Jon BTW, the site is very non-exotic. GenericUserFolder with a lot of static content and one ZCatalog w/CatalogAware ZClass.
On 9 Mar 2000, Jon Prettyman wrote:
Under load (not too heavy, but busy) the Zope process SILENTLY stops. I get no traceback info anywhere that I can see. Nothing to stdout/stderr, nothing in Z2.log.
What a coincidence. I have exactly the same problem. One site with GUF and a CatalogAware ZClass which silently stops after some time. No errors. The problem with GUF and DEBUG mode relates to lost filedescriptors. Someone posted an explanation (maybe a patch too). You might be able to locate it by doing a search on the list. Please let me know if you find something out. Pavlos
Pavlos Christoforou wrote:
On 9 Mar 2000, Jon Prettyman wrote:
Under load (not too heavy, but busy) the Zope process SILENTLY stops. I get no traceback info anywhere that I can see. Nothing to stdout/stderr, nothing in Z2.log.
What a coincidence. I have exactly the same problem. One site with GUF and a CatalogAware ZClass which silently stops after some time. No errors.
The problem with GUF and DEBUG mode relates to lost filedescriptors. Someone posted an explanation (maybe a patch too). You might be able to locate it by doing a search on the list.
Please let me know if you find something out.
Pavlos
I think this *might* fix the problem you guys are having. Although we aren't using GUF or CatalogAware objects, we discovered this on a system that was under pretty heavy load. diff -ur ../Zope-2.1.2-src/ZServer/medusa/http_server.py ZServer/medusa/http_server.py --- ../Zope-2.1.2-src/ZServer/medusa/http_server.py Mon Nov 15 13:53:56 1999 +++ ZServer/medusa/http_server.py Fri Feb 11 09:51:49 2000 @@ -606,7 +606,10 @@ def handle_accept (self): self.total_clients.increment() try: - conn, addr = self.accept() + conn=self.accept() + if conn: + conn, addr = conn + else: return except socket.error: # linux: on rare occasions we get a bogus socket back from # accept. socketmodule.c:makesockaddr complains that the -- Nick Garcia | ngarcia@codeit.com CodeIt Computing | http://codeit.com
Do these sudden disapearances leave core files? -Michel Pavlos Christoforou wrote:
On 9 Mar 2000, Jon Prettyman wrote:
Under load (not too heavy, but busy) the Zope process SILENTLY stops. I get no traceback info anywhere that I can see. Nothing to stdout/stderr, nothing in Z2.log.
What a coincidence. I have exactly the same problem. One site with GUF and a CatalogAware ZClass which silently stops after some time. No errors.
The problem with GUF and DEBUG mode relates to lost filedescriptors. Someone posted an explanation (maybe a patch too). You might be able to locate it by doing a search on the list.
Please let me know if you find something out.
Pavlos
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
No nothing. Really weird. I have actually tried on a Zope instance that was accessed only by one person and still it will silently stop after some time. Nothing related to heavy load ... Could be related to GUF as I was getting some exceptions from GUF but they were uncorrelated in time. Pavlos On Thu, 9 Mar 2000, Michel Pelletier wrote:
Do these sudden disapearances leave core files?
-Michel
Pavlos Christoforou wrote:
On 9 Mar 2000, Jon Prettyman wrote:
Under load (not too heavy, but busy) the Zope process SILENTLY stops. I get no traceback info anywhere that I can see. Nothing to stdout/stderr, nothing in Z2.log.
What a coincidence. I have exactly the same problem. One site with GUF and a CatalogAware ZClass which silently stops after some time. No errors.
The problem with GUF and DEBUG mode relates to lost filedescriptors. Someone posted an explanation (maybe a patch too). You might be able to locate it by doing a search on the list.
Please let me know if you find something out.
Pavlos
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Is there a chance all three of these instances are GUF related? [Jon Prettyman, on Thu, 09 Mar 2000] :: I'm having a serious problem with my Zope server running in :: production. :: :: Platform: RedHat Linux 6 (2.2.12-20 kernel) :: Python 1.5.2 :: Zope 2.1.4 :: starting with: python z2.py :: as root/nobody on port 80 straight ZServer :: :: :: Under load (not too heavy, but busy) the Zope process SILENTLY stops. :: I get no traceback info anywhere that I can see. Nothing to :: stdout/stderr, nothing in Z2.log. :: :: If I start as: python z2.py -Z '' to prevent the fork and detach I :: still get no message when the crash occurs. :: :: I can't run this in DEBUG mode because I'm using GUF cookie mode to :: authenticate and the login screen ends up showing an exception error :: (by design?) :: :: If anyone can tell me how to run in DEBUG mode but make GUF still hide :: the exception error that would be a big help. [jiva@devware.com, on Thu, 09 Mar 2000] :: I have seen a couple of people mention zope lockups on here before and :: I haven't seen any myself until just recently. (I have zope on about :: 5-6 machines and this is the first time I've seen this happen) :: Anyway, how can I diagnose this problem? So far I have only seen it :: happen twice, but it was twice in the last 24 hours, and I'm getting :: ready to roll out this app to some users. I'm concerned! Anyone have :: any suggestions? :: :: Symptoms are basically that it just stops responding. The web browser :: seems to connect, but it never completes the connection. Right now I :: have it running in debug mode to see if I can catch whatever it is :: with some console logging. This is on an NT Server running NT 4.0 [Pavlos Christoforou, on Thu, 09 Mar 2000] :: On 9 Mar 2000, Jon Prettyman wrote: :: :: > :: > Under load (not too heavy, but busy) the Zope process SILENTLY stops. :: > I get no traceback info anywhere that I can see. Nothing to :: > stdout/stderr, nothing in Z2.log. :: :: What a coincidence. :: I have exactly the same problem. One site with GUF and a CatalogAware :: ZClass which silently stops after some time. No errors. :: :: The problem with GUF and DEBUG mode relates to lost filedescriptors. :: Someone posted an explanation (maybe a patch too). You might be able to :: locate it by doing a search on the list.
First, turn on debug logging: http://www.zope.org/Members/mcdonc/HowTos/DEBUG-LOG Then, try and reproduce the problem. Reproduction is the most important step (no snickers from the penut gallery!). If the debug log in incomprehensable (it might be) post the tail end of it to the list. Jon Prettyman wrote:
If anyone can help me keep this server from crashing every forty-five minutes I'll buy 'em a beer next time they're in Portland.
Ok, you can buy me one after the next PorPIGgies meeting. -Michel
participants (5)
-
Jon Prettyman -
Michel Pelletier -
Nick Garcia -
Patrick Phalen -
Pavlos Christoforou