Hello everyone, my question relates to bind9/named service. This is a webserver running CentOS 6.4, BIND 9.8.2rc1, and virtualmin/webmin with all named updates applied.

When restarting BIND, the named service takes over 60 seconds to stop. During this time, no messages are logged to /var/log/messages. Finally, at the end of the period, the following are written to the log and the service immediately stops:

Jun 12 13:43:33 d01s02 named[23965]: shutting down
Jun 12 13:43:33 d01s02 named[23965]: stopping command channel on 127.0.0.1#953
Jun 12 13:43:33 d01s02 named[23965]: no longer listening on 127.0.0.1#53
Jun 12 13:43:33 d01s02 named[23965]: no longer listening on xxx.xxx.xxx.xxx#53
Jun 12 13:43:33 d01s02 named[23965]: exiting

Please note: Starting the service is instantaneous. No problems on that end. It's the STOPPING that takes so long.

In /etc/init.d/named there is a line:
NAMED_SHUTDOWN_TIMEOUT=${NAMED_SHUTDOWN_TIMEOUT:-25}

But I changed the number from -25 to -5 and it made no difference whatsoever on the delay.


Does anyone have any idea what the service is waiting for, or why it takes so long? This seems to be a bug in newer versions of CentOS as I have noticed this issue on two different servers.

I also have a server running CentOS 6.2 and BIND 9.7.3-P3 and the issue does NOT occur - named stops within 1 second of issuing the "service named stop" command.


Any information or pointers would be greatly appreciated. As I search google, the results are focused on slow "startup" times for named, but this is not the same issue.


Thank you!

krasl

See 'Use a default value' http://wiki.bash-hackers.org/syntax/..._default_value

I know this is an old thread, but when looking for a solution to exactly same problem, I kept finding this thread and other sources of information didn't give a straightforward answer.

The problem here is the firewall configuration. The named listens on two ports — port 53 on all network interfaces, and port 953 on the loopback interface (the latter being DNS RNDC Service). Both port numbers are mentioned in your log snippet.

When it is being stopped/restarted, named waits for something on the port 953, and it hangs for a long time if the port is blocked by the firewall.

So the solution is to allow incoming connections to the port 953 on the loopback interface: