BUG? First time ndc restart with bind 8.2.1

[A.R.]

i have found the ndc restart script even in 8.2 to be unreliable
even at times real crappy...

a. rahman
systems engineer

stuart nichols wrote:

> This is a heads-up.  I don't know if it is per-se a bug.
>
> I compiled and installed bind 8.2.1 on a FreeBSD 2.2.7
> nameserver that was running bind 4.9.7-T1B.
>
> Rather than kill the old named process I did:
>
>   # ndc restart
>
> The old process was not killed.  The new process decided it
> couldn't bind to the ports and sat there doing nothing.
>
> Below are the pertinent messages from the messages file.
> [some are longer than 80 characters]
>
> Jun 23 10:57:27 ftp named[29476]: starting.  named 8.2.1 Tue Jun 22 17:27:51 GMT 1999   stu at ftp.stac.state.tx.us:/usr/local/src/bind-8.2.1/src/bin/named
> Jun 23 10:57:27 ftp named[29476]: limit files set to fdlimit (256)
> Jun 23 10:57:27 ftp named[29476]: Zone "0.0.127.IN-ADDR.ARPA" (file db.local): No default TTL set using SOA minimum instead
> Jun 23 10:57:28 ftp named[29476]: bind(dfd=20, [204.64.176.67].53): Address already in use
> Jun 23 10:57:28 ftp named[29476]: deleting interface [204.64.176.67].53
> Jun 23 10:57:28 ftp named[29476]: bind(dfd=20, [127.0.0.1].53): Address already in use
> Jun 23 10:57:28 ftp named[29476]: deleting interface [127.0.0.1].53
> Jun 23 10:57:28 ftp named[29476]: not listening on any interfaces
> Jun 23 10:57:28 ftp named[29477]: Ready to answer queries.
>
> It didn't seem to recognize the old named process.  At the command
> line it had said:
>
>   ftp# ndc restart
>   ndc: error: name server not running
>   new pid is 29477
>
> without bothering to tell me it wasn't doing anything.  The
> old named continued to answer queries.  (8.1.2 would also
> not tell you if it couldn't bind the ports, such as if you
> weren't root when you started it.  It would just sit there
> as a dangling process.  It doesn't seem to me that there
> is much point for the process to remain if it can't bind
> the ports.)
>
> Like I said, I don't know if this qualifies as a bug, but it
> doesn't seem like the best behavior.  I killed both processes
> and  ndc restart  worked fine after that.
>
> stu