Greetings -
2.5.64-mm4 and -mm5 seem more rugged than previous
kernels, but there are a couple of minor nits - one of them
is the tendency of named (which appears to work reliably
under 2.4) to go catatonic under recent 2.5.6x kernels -
More verbose kernel logging may shed some light - or is
this just a red herring? I get a tons of these in 2.5.64-mm5:
<...>
process `named' is using obsolete setsockopt SO_BSDCOMPAT
process `named' is using obsolete setsockopt SO_BSDCOMPAT
process `named' is using obsolete setsockopt SO_BSDCOMPAT
<...>
Anybody here running a compliant version of named?
(This is the bind 9.2.1 which ships with Red Hat 8.0)
Best Regards,
Joe
----- Original Message -----
From: jjs <[email protected]>
Date: Wed, 12 Mar 2003 10:29:12 -0800
To: linux kernel <[email protected]>
Subject: named vs 2.5.64-mm5
> Greetings -
>
> 2.5.64-mm4 and -mm5 seem more rugged than previous
> kernels, but there are a couple of minor nits - one of them
> is the tendency of named (which appears to work reliably
> under 2.4) to go catatonic under recent 2.5.6x kernels -
>
> More verbose kernel logging may shed some light - or is
> this just a red herring? I get a tons of these in 2.5.64-mm5:
>
> <...>
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> <...>
>
> Anybody here running a compliant version of named?
>
> (This is the bind 9.2.1 which ships with Red Hat 8.0)
I would recommend you downloading BIND 9.2.2. It fixes many
bugs. Else, try the latest BIND from RedHat's RawHide repository.
HTH
Felipe
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
jjs <[email protected]> wrote:
>
> Greetings -
>
> 2.5.64-mm4 and -mm5 seem more rugged than previous
> kernels, but there are a couple of minor nits - one of them
> is the tendency of named (which appears to work reliably
> under 2.4) to go catatonic under recent 2.5.6x kernels -
>
> More verbose kernel logging may shed some light - or is
> this just a red herring? I get a tons of these in 2.5.64-mm5:
>
> <...>
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> process `named' is using obsolete setsockopt SO_BSDCOMPAT
> <...>
>
The changelog has:
# --------------------------------------------
# 03/03/08 [email protected] 1.1083
# [NET]: Nuke SO_BSDCOMPAT.
# --------------------------------------------
Maybe James can tell us what is going on here.
We should at least place a cap on the number of times that message
is printed.
On Wed, 2003-03-12 at 11:31, Andrew Morton wrote:
> The changelog has:
>
> # --------------------------------------------
> # 03/03/08 [email protected] 1.1083
> # [NET]: Nuke SO_BSDCOMPAT.
> # --------------------------------------------
>
> Maybe James can tell us what is going on here.
>
> We should at least place a cap on the number of times that message
> is printed.
Feel free to send a patch for that.
SO_BSDCOMPAT has had ZERO side effects since 2.0.x, and it's been
thus scheduled to be removed for years. It was merely a binary
state passed in and out of the kernel to the user and had no effect
on socket behavior at all.
Any application still referencing this ancient thing either expects
some kind of different behavior from setting SO_BSDCOMPAT non-zero,
or really doesn't rely on anything at all.
Since SO_BSDCOMPAT has had zero side effects for 5 or so years, this
means that the safe change is to remove all references to SO_BSDCOMPAT
that exist in any application.
So, the SO_BSDCOMPAT messages are in all
likelihood unrelated to the problems I'm seeing
with bind-9.2.1 under 2.5.6x-recent kernels...
I guess I'll have to turn up the debugging on
bind and see if anything unusual pops up -
Joe
David S. Miller wrote:
>On Wed, 2003-03-12 at 11:31, Andrew Morton wrote:
>
>
>>The changelog has:
>>
>># --------------------------------------------
>># 03/03/08 [email protected] 1.1083
>># [NET]: Nuke SO_BSDCOMPAT.
>># --------------------------------------------
>>
>>Maybe James can tell us what is going on here.
>>
>>We should at least place a cap on the number of times that message
>>is printed.
>>
>>
>
>Feel free to send a patch for that.
>
>SO_BSDCOMPAT has had ZERO side effects since 2.0.x, and it's been
>thus scheduled to be removed for years. It was merely a binary
>state passed in and out of the kernel to the user and had no effect
>on socket behavior at all.
>
>Any application still referencing this ancient thing either expects
>some kind of different behavior from setting SO_BSDCOMPAT non-zero,
>or really doesn't rely on anything at all.
>
>Since SO_BSDCOMPAT has had zero side effects for 5 or so years, this
>means that the safe change is to remove all references to SO_BSDCOMPAT
>that exist in any application.
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
>
David S. Miller wrote:
>If bind errors internally because it cannot
>set SO_BSDCOMPAT, this is likely the problem.
>
>You need to hack the bind sources to remove references
>to SO_BSDCOMPAT.
>
Aha (light bulb goes on) -
OK, I'll take a look at the bind code and see...
Thanks for the clue -
Joe
From: jjs <[email protected]>
Date: Wed, 12 Mar 2003 14:28:02 -0800
So, the SO_BSDCOMPAT messages are in all
likelihood unrelated to the problems I'm seeing
with bind-9.2.1 under 2.5.6x-recent kernels...
I guess I'll have to turn up the debugging on
bind and see if anything unusual pops up -
If bind errors internally because it cannot
set SO_BSDCOMPAT, this is likely the problem.
You need to hack the bind sources to remove references
to SO_BSDCOMPAT.