What could have caused the following error?
martin at dc.cis.okstate.edu
Thu Jun 6 01:07:41 UTC 2002
It gets more interesting. After I got away from it for a
bit, I thought to also look at syslog to see if anything was left
there. In the process, I discovered that some of that pattern of
interface failure had been happening about once an hour all day
but bind was still mostly answering queries. Things weren't as
healthy as I first thought.
What I had done to minimize down time after the upgrade
may have contributed to the problem.
After installing the port of bind under FreeBSD, the
bind9.0 named was still running since it hadn't been stopped yet.
I don't remember if I killed it using rndc stop or did a kill
`cat pidfile`, but I did the kill command;restart. I do start it
from root but use the -t flag to run it in the sandbox.
Maybe a process was still left over from the old bind.
Here is what the syslog showed.
Jun 5 07:56:06 hostname named:
starting BIND 9.2.1 -t /var/named -u 65533 -cetc/named.conf
using 1 CPU
loading configuration from '/etc/named.conf'
listening on IPv4 interface fxp0, 139.78.x.x#53
could not listen on UDP socket: address in use
creating IPv4 interface fxp0 failed; interface ignored
When I manually killed and restarted it after it stop
working all together, it restarted without any of those errors and
appears to be running normally.
How did I miss something so obvious? Our syslog file is
extremely busy with dhcp entries and I am used to looking at the
log file specifically for named. It confirms that the stop time
for bind9.0 was 7:56:06 and the first message about the local
zone loading was also 7:56:06.
I shouldn't have been so quick on the trigger but maybe
some of this information will be useful.
The first interface problem message is exactly one hour
in to the log at 08:56.
More information about the bind-users