Your message dated Sun, 28 Oct 2012 22:09:41 +0100
with message-id <[email protected]>
and subject line Closing very old bind9 bugs
has caused the Debian Bug report #175508,
regarding bind9 on Alpha is non-working
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
175508: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=175508
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bind9
Version: 1:9.2.1-7
Severity: important
Tags: sid
bind9 on x86 seems to be fine. It runs as my primary. My secondary runs on
an alpha (PC164LX). It starts up, emits error messages, and thereafter
simply uses up system resources, filling up the kernel udp buffers and
generally making the system painfully slow for anything that has to resolve
names (which means timing out on this server, because it won't answer).
/var/log/daemon.log looks like this:
Jan 1 23:35:28 talifane named[2958]: starting BIND 9.2.1
Jan 1 23:35:28 talifane named[2958]: using 1 CPU
Jan 1 23:35:28 talifane named[2960]: loading configuration from
'/etc/bind/named.conf'
Jan 1 23:35:28 talifane named[2960]: net.c:66: unexpected error:
Jan 1 23:35:28 talifane named[2960]: socket() failed: Success
Jan 1 23:35:28 talifane named[2960]: no IPv6 interfaces found
Jan 1 23:35:28 talifane named[2960]: listening on IPv4 interface lo,
127.0.0.1#53
Jan 1 23:35:28 talifane named[2960]: listening on IPv4 interface eth0,
192.168.0.26#53
Jan 1 23:35:28 talifane named[2960]: command channel listening on 127.0.0.1#953
Jan 1 23:35:28 talifane named[2960]: zone 0.in-addr.arpa/IN: loaded serial 1
Jan 1 23:35:28 talifane named[2960]: zone 127.in-addr.arpa/IN: loaded serial 1
Jan 1 23:35:28 talifane named[2960]: zone 0.168.192.in-addr.arpa/IN: loaded
serial 20021226
Jan 1 23:35:28 talifane named[2960]: zone 255.in-addr.arpa/IN: loaded serial 1
Jan 1 23:35:28 talifane named[2960]: zone talsever.com/IN: loaded serial
20021227
Jan 1 23:35:28 talifane named[2960]: zone localhost/IN: loaded serial 1
Jan 1 23:35:28 talifane named[2960]: running
Jan 1 23:35:28 talifane named[2960]: UDP client handler shutting down due to
fatal receive error: file not found
Jan 1 23:35:28 talifane named[2960]: UDP client handler shutting down due to
fatal receive error: file not found
Jan 1 23:35:28 talifane named[2960]: zone 0.168.192.in-addr.arpa/IN: sending
notifies (serial 20021226)
Jan 1 23:35:28 talifane named[2960]: zone talsever.com/IN: sending notifies
(serial 20021227)
Jan 1 23:35:28 talifane named[2960]: dispatch 0x120092ef0: odd socket result
in udp_recv(): file not found
Jan 1 23:35:29 talifane named[2960]: dispatch 0x120092ef0: odd socket result
in udp_recv(): file not found
Jan 1 23:35:29 talifane named[2960]: socket.c:2964: unexpected error:
Jan 1 23:35:29 talifane named[2960]: 2/No such file or directory
Jan 1 23:35:29 talifane named[2960]: transfer of '0.168.192.in-addr.arpa/IN'
from 192.168.0.18#53: failed setting up socket: unexpected error
Jan 1 23:35:29 talifane named[2960]: transfer of '0.168.192.in-addr.arpa/IN'
from 192.168.0.18#53: end of transfer
Jan 1 23:35:29 talifane named[2960]: transfer of '0.168.192.in-addr.arpa/IN'
from 192.168.0.18#53: zone transfer setup failed
Jan 1 23:35:29 talifane named[2960]: dispatch 0x120092ef0: odd socket result
in udp_recv(): file not found
The last line repeats about a dozen times, and then the entire software
suite seems to enter limbo, neither answering queries nor updating the log.
Several of the error messages are a little screwy. socket() failed:
Success, for instance, looks like a classic NT error message. The critical
bit seems to be that the UDP client handler dies. It would be nice to know
which file it is that isn't found.
I can provide additional debugging information as seems useful; let me know
what parameters to run with, and I can send on the results.
The current workaround is to disable the nameserver on this machine. This
is not a critical problem for me, but sites running all of their dns on
Alpha boxen (or even primaries, perhaps) are going to be hurting badly.
I do not know when this problem appeared; it was not a problem when this box
was running the testing, rather than the unstable distribution. That update
happened within the last week, and performance has been hideous since. Note
that it says "testing/unstable", but it's been dist-upgraded to unstable.
-- System Information:
Debian Release: testing/unstable
Architecture: alpha
Kernel: Linux talifane 2.4.19 #1 Sat Aug 3 10:33:38 EDT 2002 alpha
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages bind9 depends on:
ii adduser 3.49 Add and remove users and groups
ii libc6.1 2.3.1-8 GNU C Library: Shared libraries an
ii libdns5 1:9.2.1-7 DNS Shared Library used by BIND
ii libisc4 1:9.2.1-7 ISC Shared Library used by BIND
ii libisccc0 1:9.2.1-7 Command Channel Library used by BI
ii libisccfg0 1:9.2.1-7 Config File Handling Library used
ii liblwres1 1:9.2.1-7 Lightweight Resolver Library used
ii libssl0.9.6 0.9.6g-10 SSL shared libraries
ii netbase 4.09 Basic TCP/IP networking system
-- no debconf information
--- End Message ---
--- Begin Message ---
Since this bug references a BIND 9 version that is even older than
oldstable (lenny) I'm closing it.
Please reopen if reproducible in newer versions.
--- End Message ---
