I hope you dont mind me replying to the list... Actually, if registering a SIGPIPE signal handler "fixes" the problem, that is a perfectly ok thing to do and probably should become part of Zope startup. Does this actually fix the problem? It'd be nice to understand the problem better though. Maybe you could report the problem to one or both of the DA maintainers (if they're not reading the list) to see if they have any clues. - C ----- Original Message ----- From: "Doyon, Jean-Francois" <Jean-Francois.Doyon@CCRS.NRCan.gc.ca> To: "'Chris McDonough'" <chrism@zope.com> Sent: Friday, March 22, 2002 5:28 PM Subject: SOLVED !!! (sorta) RE: [Zope] System performance threads/proccesses & random crashes (SIGPIPE)
Chris,
OK, it's official, the signal handling problem was coming from the PostgreSQL Database adapters! Since the problem was occuring with BOTH adapters, and I found no reference to signals in their source code, I have ot assume it's the PostgreSQL client libs that are wrapped in python that somehow interfere with the signal handling.
I removed BOTH database adapters from my installation, removed the signal trapping, retsarted, and did the "quick double click" trick, and bingo, I got the ZServer errors, but none of the horrible crashing problems with AIEEEE and error 500's ....
The question now is: how do we fix this in a sensible manner? I will try and contact the people from both of those DB interfaces to see if they have any ideas, but maybe there's a Zope way to do it (Better in the sense that you can control the problem centrally, insted of having to change all of the DA's).
I guess for now I will re-instate my signal trapping code, but a better solution should be found. Since you may be more familiar with this kind of stuff, how would you suggest I go about this?
Thanks for everything, that was a fun littl eafternoon of debugging ... If you're ever in Ottawa I'll buy you a beer!
Cheers, J.F.
-----Original Message----- From: Chris McDonough [mailto:chrism@zope.com] Sent: Friday, March 22, 2002 4:53 PM To: Chris McDonough; Doyon, Jean-Francois; zope@zope.org; matt@zope.com Subject: Re: [Zope] System performance threads/proccesses & random crashes (SIGPIPE)
You know, something comes to mind. When a UNIX process forks, it copies its signal handler state to the child's process space. I dont know exactly how the FastCGI stuff invokes Zope, but it may be that Python only installs a SIGPIPE SIG_IGN handler if one isn't inherited from a parent process. Setting it explicitly in z2.py ala the below message might cause your problem to be solved if so.
----- Original Message ----- From: "Chris McDonough" <chrism@zope.com> To: "Doyon, Jean-Francois" <Jean-Francois.Doyon@CCRS.NRCan.gc.ca>; <zope@zope.org>; <matt@zope.com> Sent: Friday, March 22, 2002 4:41 PM Subject: Re: [Zope] System performance threads/proccesses & random crashes (SIGPIPE)
A couple of more things:
This, so far as I can tell is a bug in the FastCGI implementation (Not handling SIGPIPE as suggested). Should I report it somewhere?
The bit you passed along from the FastCGI website seems to intimate that the behavior is expected... I'm not sure where you would report it. ;-)
Python installs a small number of signal handlers by default: SIGPIPE is ignored (so write errors on pipes and sockets can be reported as ordinary Python exceptions)
I didn't know this. It appears Python already installs SIG_IGN as the signal handler for a SIGPIPE signal... mm. I'm not sure how your configuration manages to get around this. I'd have to guess that some product is resetting the signal handler.
And finally, how do I "ignore" a signal ? I guess just writing a "pass" will work ? I'll try it out, I guess on reception of a signal, only one handler is a called once?
import signal signal.signal(signal.SIGPIPE, signal.SIG_IGN)
This installs a null signal handler for the SIGPIPE signal.
I wonder if you could find the place in the code where the exception occurs when you click a lot and place a "print signal.getsignal(signal.SIGPIPE)" right before the place that the error happens. See if it's 1. If it's 1... well, I'm not sure. I dont know how the process could be killed by a SIGPIE then.
If it's 0, that means that something has installed a signal handler on top of Python's default "ignore SIGPIPE" signal handler, and you might be able to find it by grepping for "SIGPIPE" or "13" in your code.
- C
_______________________________________________ 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 )