SOLVED !!! (sorta) RE: [Zope] System performance threads/proc cesses & random crashes (SIGPIPE)

[Doyon, Jean-Francois]

Not at all,

Yes, registering a SIGPIPE handler that does nothing in z2.py fixes the
problem.

And I have sent an e-mail to the DA maintainers, as well as python and
postgres people to try and better understand the problem.

J.F.


-----Original Message-----
From: Chris McDonough [mailto:chrism@zope.com]
Sent: Friday, March 22, 2002 6:32 PM
To: Doyon, Jean-Francois; zope@zope.org
Subject: Re: SOLVED !!! (sorta) RE: [Zope] System performance
threads/proccesses & random crashes (SIGPIPE)


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 )
> >
>