upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-25 08:07:12 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Q: Why do we get the following warning at run time:

Browse source 
kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT
This commit is contained in:
Mark Andrews 2007-01-31 23:19:45 +00:00
parent a5f1fd26b0
commit 51f883e0a5
2 changed files with 77 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
FAQ
View file

@ -673,3 +673,31 @@ A: No, so long as the machines internal clock (as reported by "date -u") remains
setting the TZ envirionment variable appropriately. See your OS's documentation
for more details.
Q: Why do we get the following warning at run time:
kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT
A: The early Linux kernels broke sendto() by having it return that a ICMP
unreachable had be received for non connected UDP sockets. This made non
connected UDP sockets work like connected UDP socket which is fine when you are
only talking to one destination. Named however talks to multiple destinations
and it caused problems.
Rather than fix sendto() to just have BSD behaviour they added SO_BSDCOMPAT to
turn BSD behaviour on/off on a per socket basis.
Later they decided to make BSD behaviour the default and to aggressively
trackdown application that used SO_BSDCOMPAT by issuing a warning. This is the
sort of things vendors do in alpha/beta stages of a release so that their code
is clean. They then turn the warning *off* for release code.
We still have customers that have kernels that require SO_BSDCOMPAT to operate.
We therefore cannot remove the setsockopt(SO_BSDCOMPAT) call.
Now most/all portable applications that use SO_BSDCOMPAT use it conditionally
manner so just removing SO_BSDCOMPAT from the header file would be safe as long
as the binary was not to be moved between systems. BIND's use is conditional.
In short, the Linux developers should either, remove the #define for
SO_BSDCOMPAT, and/or remove the warning.

50
FAQ.xml
View file

@ -18,7 +18,7 @@
- PERFORMANCE OF THIS SOFTWARE.
-->
<!-- $Id: FAQ.xml,v 1.16 2007/01/12 00:14:50 marka Exp $ -->
<!-- $Id: FAQ.xml,v 1.17 2007/01/31 23:19:45 marka Exp $ -->
<article class="faq">
<title>Frequently Asked Questions about BIND 9</title>
@ -1210,6 +1210,7 @@ named_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,d
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
@ -1240,6 +1241,7 @@ zone "list.dsbl.org" {
</programlisting>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
@ -1273,5 +1275,51 @@ zone "list.dsbl.org" {
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>
Why do we get the following warning at run time:
<programlisting>kernel: process `named' is using obsolete setsockopt SO_BSDCOMPAT</programlisting>
</para>
</question>
<answer>
<para>
The early Linux kernels broke sendto() by having it return
that a ICMP unreachable had be received for non connected
UDP sockets. This made non connected UDP sockets work like
connected UDP socket which is fine when you are only talking
to one destination. Named however talks to multiple
destinations and it caused problems.
</para>
<para>
Rather than fix sendto() to just have BSD behaviour they added
SO_BSDCOMPAT to turn BSD behaviour on/off on a per socket basis.
</para>
<para>
Later they decided to make BSD behaviour the default and
to aggressively trackdown application that used SO_BSDCOMPAT
by issuing a warning. This is the sort of things vendors
do in alpha/beta stages of a release so that their code is
clean. They then turn the warning *off* for release code.
</para>
<para>
We still have customers that have kernels that require
SO_BSDCOMPAT to operate. We therefore cannot remove the
setsockopt(SO_BSDCOMPAT) call.
</para>
<para>
Now most/all portable applications that use SO_BSDCOMPAT use it
conditionally manner so just removing SO_BSDCOMPAT from the
header file would be safe as long as the binary was not to
be moved between systems. BIND's use is conditional.
</para>
<para>
In short, the Linux developers should either, remove the #define for
SO_BSDCOMPAT, and/or remove the warning.
</para>
</answer>
</qandaentry>
</qandaset>
</article>