named vs 2.5.64-mm5

named vs 2.5.64-mm5

[jjs]

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

Re: named vs 2.5.64-mm5

[Felipe Alfaro Solana]

----- Original Message ----- 
From: jjs <jjs@tmsusa.com> 
Date: 	Wed, 12 Mar 2003 10:29:12 -0800 
To: linux kernel <linux-kernel@vger.kernel.org> 
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

Re: named vs 2.5.64-mm5

[Andrew Morton]

jjs <jjs@tmsusa.com> 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      jmorris@intercode.com.au        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.

Re: named vs 2.5.64-mm5

[David S. Miller]

On Wed, 2003-03-12 at 11:31, Andrew Morton wrote:
> The changelog has:
> 
> # --------------------------------------------
> # 03/03/08      jmorris@intercode.com.au        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.

Re: named vs 2.5.64-mm5

[jjs]

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      jmorris@intercode.com.au        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 majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
>
>  
>

Re: named vs 2.5.64-mm5

[David S. Miller]

   From: jjs <jjs@tmsusa.com>
   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.

Re: named vs 2.5.64-mm5

[jjs]

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