Re: Fwd: 2.0.24 - Apache Dies?

Dan Merillat (
Sun, 3 Nov 1996 13:32:27 -0500 (EST)

On Sun, 3 Nov 1996, G Sumner Hayes wrote:

> Date: Sun, 3 Nov 1996 13:05:26 -0500 (EST)
> From: G Sumner Hayes <>
> To:
> Subject: Fwd: 2.0.24 - Apache Dies?
> I haven't seen this mentioned here yet, so I thought I'd forward it
> along. I haven't experienced the problem personally, but several
> people have mentioned it on comp.os.linux.development.system.
> ---------- Forwarded message begins here ----------
> From: (Inconnu)
> Newsgroups: comp.os.linux.development.system
> Subject: Re: 2.0.24 - Apache Dies?
> Message-ID: <55hk50$>
> References: <55fsmi$>
> In article <55fsmi$>, Greg Boehnlein <> wrote:
> ->I've just compiled a fresh 2.0.24 kernel on two extremely high volume web
> ->servers and I'm noticing that after a while, the Apache server (1.1.1)
> ->crashes and burns.
> Same here.


> ->All child servers die and a single server is left running that cannot be
> ->kill -9'ed, or destroyed in any other way than a reboot. This server ends
> ->up hogging the CPU.
> Exactly the same problem we have-- we do a lot of development with the
> server (testing out CGI perl programs) and it'll die within an hour;
> no explanation in the log files.

Hmm... I could kill it though.... just when I restarted it died again

> ->Does anyone have a fix for this? Is it something that I should patch in
> ->Apache? Or is this a kernel bug.
> I orginally had a cron job go out and re-start the server every hour, but
> it was a bad idea since the system may crash inbetween; I gave up and
> put it under inetd and it works just fine (albeit SLOWLY)
> ->On a side note, on those machines running 2.0.24 netstat displays an
> ->inordinate amount of sockets in the CLOSE and CLOSE_WAIT states.
> It always does that-- I noticed problems when I upgraded to 2.0.23 and it
> still exists in 2.0.24

I fixxed by reverting to 2.0.0 (which is what it was running before) and
manually applying the 2 major patches (ping_bomb and synflood) So it's
somewhere between those.