The following reply was made to PR general/3046; it has been noted by GNATS.

From: [EMAIL PROTECTED] (Miles O'Neal)
To: [EMAIL PROTECTED] (Marc Slemko)
Cc: [EMAIL PROTECTED]
Subject: Re: general/3046: Apache letting child processes run too long
Date: Wed, 23 Sep 1998 11:41:08 -0500 (CDT)

 Marc Slemko said...
 |
 |That's all very nice, but just because it runs other things fine doesn't
 |mean it will run everything fine...
 
 Duh.  My point was that it's not a piece of useless crap as
 your email implied.
 
 |It obviously doensn't run fine since you are complaining it doesn't.  We
 |have had to track down OS bugs over and over due to people using old
 |versions of the OS, compiler, etc. and we just don't have the resources to
 |do so when it doesn't impact the vast majority of users.
 
 How do you know who it impacts?  Maybe nobody noticed it.
 It's non-critical, so the impact is minimal.  If you don't
 want to work on it, just say so.
 
 All I'm asking is that you *look* at the problem instead of just 
 assuming* it isn't an Apache bug.  I make no such assumptions,
 and if it's my system, fine.
 
 I have similar behavior at work, on a FreeBSD system, where I have:
 
    MaxRequestsPerChild 100
 
 and it kills the child and forks a new one at 30 or 31 (granted,
 it's still using Apache 1.2.5, but it's a similar problem).
 
 
 |Erm... this is not the output of the status page.  This is parsed by
 |something.
 
 Wrong.  The default status page outputs TABLE tags.  Cutting
 and pasting TABLE output (at least from my version of Navigator
 into vi) results in unusable formatting.  So I used the "notable"
 option to the status module.  It's a *standard* part of the
 status module.
 
 Try it: /status?notable .
 
 |Does this happen with a base Apache without any extra modules or
 |modificatoins?
 
 That's what I'm using.  If I'd had extra modules or hacks, I'd have
 said so where it asked on the bugs form.
 
 |I'm not sure what you are talking about with "kill the child" number.
 
 The number of accesses per child, after which it *really* kills the child
 and forks a new process, instead of the number set in the config file.
 
 -Miles

Reply via email to