httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] Child processes signalling server abort
Date Sat, 02 May 1998 20:59:03 GMT


On Sat, 2 May 1998, Marc Slemko wrote:

> On Sat, 2 May 1998, Dean Gaudet wrote:
> 
> > 
> > 
> > On Sat, 2 May 1998, Marc Slemko wrote:
> > 
> > > Would it be a good thing to wait until we have a few child processes
> > > exiting with childfatal over a certain period before the parent exits?
> > > It may be possible that some freak error could cause one normally
> > > fatal error.  We don't want the whole thing to exit too quickly.
> > 
> > I'm not sure it's worth it.  I'd rather see the patch go into use, and if
> > we find that it can exit too easily then we can fix that... the reason I'm
> > concerned is because we'd have to define what a good rate of fatals is,
> > and we'd have to get that code correct.  What Jim has now is simple, and
> > we can be certain that it'll stop things when they should be stopped.
> 
> But the problem is that it can also bring the entire server to a crashing
> halt if there is some situation we aren't aware of.  I don't know if that
> is acceptable.

I know this, but I'm also unconvinced that we'll successfully get
rate-based code to work.  And that is far worse -- because the server
consumes the entire machine... and yes if you want to argue that the spawn
32 per second shouldn't keep doing 32 per seconds for long... but that's
just a case where we didn't get rate based code correct :)

As an admin, when I can't log into my server to fix it because some errant
daemon is chewing all the cpu by spawning and killing off children, I'm
WAY more pissed than if a daemon just died.  I've already got scripts
which check for a dead httpd (it can happen even without bugs in our code
-- consider a memory error leading to segfault in the parent).  Those
scripts will at least have the opportunity to work.  They may not have the
opportunity if we attempt some fancy rate-based scheme. 

(And my scripts run once per minute, rather than once per second.) 

> That is bad.  Having the server keep running and not work is better in my
> books than exiting when it shouldn't.  This assumes, of course, a
> dedicated machine for the server.

This is a bad assumption as well.  Suppose it is a dedicated machine, in
that case the service is obviously important enough that the admin
probably has pagers trigger when the service dies, and/or has a restart
script like I have.  If it isn't a dedicated machine then your suggestion
lets apache take over the entire machine -- locking out other uses.  So
either way it's a loss. 

So I argue for simplicity... unless you can come up with a neato scheme. 

Dean



Mime
View raw message