Re: cvs commit: apache-1.3/src/main http_main.c

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

>-1.  I'm backing this out.  Any such problems are problems with 3rd party
>modules and libraries, and it is the module implementor's job to fix them. 
>Furthermore, this doesn't cover all the crap a library/module could fuck
>up, like setrlimit().  Surely you're not going to cover a libraries butt
>in that area... just like we don't do anything to close all the
>descriptors not listed in a pool.  If a library/module NEEDS this cleanup
>then they can damn well register a cleanup.

Okay by me -- I was just trying to fix the problem that Marc mentioned
a while back.  It is more likely to occur with database libraries than
anything else, so I suppose a database interface module like mod_php
could handle it on their own.  This is one hell of a hard thing to debug
though.

....Roy

Re: cvs commit: apache-1.3/src/main http_main.c

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> My other suggestion would probably work better though -- use SIGUSR2
> between parent and child, and stick in a SIGALRM handler which logs "hey
> there, wow, I got a SIGALRM, you've got a screwed up module!"  Then you'll
> find out if in fact you do have the bug.  (And if you install the handler
> with SA_RESTART then you don't even need to fix up anything.) 

I like this approach.  It's pretty rough debugging this stuff from a PHP
perspective because I am pulling in a whole bunch of 3rd-party libraries.
It is hard to figure out what exactly these libraries are doing sometimes,
especially for the ones that do not come with source.

-Rasmus

Re: cvs commit: apache-1.3/src/main http_main.c

[Dean Gaudet <dg...@arctic.org>]

On Mon, 4 Jan 1999, Marc Slemko wrote:

> On Mon, 4 Jan 1999, Dean Gaudet wrote:
> 
> > On Sun, 3 Jan 1999, Marc Slemko wrote:
> > 
> > > Yea, I don't know that this is a good thing to do by default either.
> > > However, I keep running into situation after situation where something
> > > screws this up.  Perhaps the code I'm dealing with is too horrible, but
> > > I really don't think that is the case.
> > > 
> > > I would go for a compile time (yuck yuck, compiletime bad) or runtime
> > > config option to enable a "reset alarm and handler" call at the end of
> > > each response, but default to off.
> > 
> > My other suggestion would probably work better though -- use SIGUSR2
> > between parent and child, and stick in a SIGALRM handler which logs "hey
> > there, wow, I got a SIGALRM, you've got a screwed up module!"  Then you'll
> > find out if in fact you do have the bug.  (And if you install the handler
> > with SA_RESTART then you don't even need to fix up anything.) 
> 
> Mmm.  Maybe.
> 
> You still have to keep reinstalling the SIGALRM handler though, since
> otherwise some wonderful code will install its own handler then reset it
> to default, ie. kill the thing.  That does give you a nice log saying
> "oops, this child exited on SIGALRM" but hurts anything it may not be
> doing.

OK, once you get the first SIGALRM like this, turn on your "reset alarm
and handler" feature.  You could even put the enabler for it into the
global scoreboard, since we really only care about it in OPTIMIZE_TIMEOUTS
-- which has a shared mem scoreboard.

Dean

Re: cvs commit: apache-1.3/src/main http_main.c

[Marc Slemko <ma...@worldgate.com>]

On Mon, 4 Jan 1999, Dean Gaudet wrote:

> On Sun, 3 Jan 1999, Marc Slemko wrote:
> 
> > Yea, I don't know that this is a good thing to do by default either.
> > However, I keep running into situation after situation where something
> > screws this up.  Perhaps the code I'm dealing with is too horrible, but
> > I really don't think that is the case.
> > 
> > I would go for a compile time (yuck yuck, compiletime bad) or runtime
> > config option to enable a "reset alarm and handler" call at the end of
> > each response, but default to off.
> 
> My other suggestion would probably work better though -- use SIGUSR2
> between parent and child, and stick in a SIGALRM handler which logs "hey
> there, wow, I got a SIGALRM, you've got a screwed up module!"  Then you'll
> find out if in fact you do have the bug.  (And if you install the handler
> with SA_RESTART then you don't even need to fix up anything.) 

Mmm.  Maybe.

You still have to keep reinstalling the SIGALRM handler though, since
otherwise some wonderful code will install its own handler then reset it
to default, ie. kill the thing.  That does give you a nice log saying
"oops, this child exited on SIGALRM" but hurts anything it may not be
doing.

Re: cvs commit: apache-1.3/src/main http_main.c

[Dean Gaudet <dg...@arctic.org>]

On Sun, 3 Jan 1999, Marc Slemko wrote:

> Yea, I don't know that this is a good thing to do by default either.
> However, I keep running into situation after situation where something
> screws this up.  Perhaps the code I'm dealing with is too horrible, but
> I really don't think that is the case.
> 
> I would go for a compile time (yuck yuck, compiletime bad) or runtime
> config option to enable a "reset alarm and handler" call at the end of
> each response, but default to off.

My other suggestion would probably work better though -- use SIGUSR2
between parent and child, and stick in a SIGALRM handler which logs "hey
there, wow, I got a SIGALRM, you've got a screwed up module!"  Then you'll
find out if in fact you do have the bug.  (And if you install the handler
with SA_RESTART then you don't even need to fix up anything.) 

Dean

Re: cvs commit: apache-1.3/src/main http_main.c

[Marc Slemko <ma...@worldgate.com>]

Yea, I don't know that this is a good thing to do by default either.
However, I keep running into situation after situation where something
screws this up.  Perhaps the code I'm dealing with is too horrible, but
I really don't think that is the case.

I would go for a compile time (yuck yuck, compiletime bad) or runtime
config option to enable a "reset alarm and handler" call at the end of
each response, but default to off.

On Sun, 3 Jan 1999, Roy T. Fielding wrote:

> >-1.  I'm backing this out.  Any such problems are problems with 3rd party
> >modules and libraries, and it is the module implementor's job to fix them. 
> >Furthermore, this doesn't cover all the crap a library/module could fuck
> >up, like setrlimit().  Surely you're not going to cover a libraries butt
> >in that area... just like we don't do anything to close all the
> >descriptors not listed in a pool.  If a library/module NEEDS this cleanup
> >then they can damn well register a cleanup.
> 
> Okay by me -- I was just trying to fix the problem that Marc mentioned
> a while back.  It is more likely to occur with database libraries than
> anything else, so I suppose a database interface module like mod_php
> could handle it on their own.  This is one hell of a hard thing to debug
> though.
> 
> ....Roy
>