RE: named failing to restart after updating to RHEL3 U4

[Tom Sightler <ttsig tuxyturvy com>]

On Wed, 2004-12-22 at 14:33 +0100, Mimmus wrote:
> > (if I had installed the disaster that was the 2.4.21-20.EL kernel on our 
> > most
> > critical production Oracle servers I might be looking for a new job)
> 
> We had problems with earlier 2.4.21-9 due to an infamous problem with 
> hugetlbs (Metalink  Oracle Doc. 262004.1/Bug 3570979).
> We recently updated our 'biggest' Oracle 9.2.0.5 servers (two HP DL740 with 
> 8 CPUs and 32 GB od RAM) to 2.4.21-20.EL (and patched Oracle), solving 
> problems..
> What other risks are we running now?

I'm guessing your talking about the high system usage with VLM?  (I
didn't actually look at the bug you posted).  That was one of the
reasons we were looking forward to testing 2.4.21-20.EL, but after we
had three development systems crash in a few weeks due to Bugzilla
132639 we were forced to revert to 2.4.21-15.0.x.EL and revert the
Oracle patch.

Almost every Linux admin that I know personally has been bit by this
bug.  Redhat continued to push the kernel with no update for months.
Quite frustrating.  The bug was actually intoduced in U3 (other kswapd
bugs existed in older kernels, but I don't know if they were this bad).

That being said, I have several systems that have been running 100+ days
on 2.4.21-20.EL, so it doesn't hit every system.

Also, on a bug introduced in the aacraid driver in 2.4.20-20.EL caused
several of our systems to oops.

The real point is that both of these issues, which affected 50% of our
servers (we only have 14 Redhat servers) didn't exist with 2.4.20-15.0.x
kernels.  Had I turned on autoupdate, and just let 2.4.21-20.EL push out
to every server, rather than selectively picking various servers to
update manually, it could have been a real disaster.  As it was, it was
just annoying, but didn't get the management exposure if it had been our
production system crashing.

Later,
Tom