On Mon, 29 Jan 2001, Robert Landrum wrote:
> I did the exact same thing... But the kill(-9,$pid) didn't work, even
> when run as root. Unfortunatly, Apache::Watchdog::RunAway is just as
> lame as our solutions (Sorry Stas), in that it relies on an external
> process that checks the apache scoreboard and kills anything that's
> been running for "X" amount of time.
Yep, we've had a few of these too -- but it seems I can avoid these if I
kill the runaways early enough before they become too brain dead.
> You could, in theory just reduce the "Timeout" option in apache to
> "X" above to achieve the same result, and avoid the external process
> altogether.
Hmmm, are you sure about that? According to the apache manual:
The TimeOut directive currently defines the amount of time Apache
will wait for three things:
1.The total amount of time it takes to receive a GET request.
2.The amount of time between receipt of TCP packets on a POST
or PUT request.
3.The amount of time between ACKs on transmissions of TCP packets
in responses.
I've never known 'Timeout' to affect the amount of time a child process
takes to service a request though...
> The problem, I'm afraid, is that I start hemorrhaging memory at the
> rate about 4 megs per second, and after 300 seconds, I have a process
> with just over 1200 megs of memory. The machine itself handles this
> fine, but if the user stops and does whatever it is they're doing
> again, I end up with two of those 1200 meg processes... which the
> machine cannot handle.
>
> I'm hoping someone else has a more sophisticated solution to tracing
> runaway processes to their source. If not, I'll have to write some
> internal stuff to do the job...
Afraid I can't offer anything better than what it sounds like you already
have...
<Steve>
=-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
Steve Reppucci [EMAIL PROTECTED] |
Logical Choice Software http://logsoft.com/ |
