7.1 BIND Name Server Signals

In day-to-day operation, the BIND name server, named, is manipulated with signals. We'll use them in this chapter and in other chapters. Here's a list of the signals you can send to a name server and a short description of the action each signal causes. Each of these signals will be discussed in more detail elsewhere in this book. (On some systems, the files listed below will be found in /var/tmp instead of /usr/tmp.)

HUP

Reload the name server. Send this signal to a primary master name server after modifying its configuration file or one of its database files. Send this signal to a 4.9 or later slave name server to cause it to update its slave zones if they are not current.

INT

Dump a copy of the name server's internal database to named_dump.db in /usr/tmp (version 4) or in the name server's current directory (version 8).

ABRT (version 4)

Append the name server's statistics to /usr/tmp/named.stats. This signal may be called IOT on your system.

ILL (version 8)

Append the name server's statistics to named.stats in the name server's current directory.

USR1

Append debugging information to named.run in /usr/tmp (version 4) or in the name server's current directory (version 8). Each subsequent USR1 signal increases the amount of detail in the debugging information. For information on what is logged at each level, see Chapter 12, Reading BIND Debugging Output.

USR2

Turn off debugging.

WINCH

Toggle logging all queries with syslog. Logging takes place at priority LOG_INFO. named must be compiled with QRYLOG defined (it is defined by default). This feature did not exist in version 4.8.3.

TERM (version 8)

Exit and save dynamic zones to files.

The 4.9 and later distributions provide a handy shell script for sending these signals, called ndc. Check out the manpage for the command syntax or just run ndc without any options and it will display a usage message. Be careful not to use a BIND 4 version of ndc with a BIND 8 name server since the signal to send for statistics has changed. If you don't have ndc, you'll have to send the signals manually. Read on.

To send a name server a signal, you must first find the name server's process ID. The BIND name server leaves its process ID in a disk file, making it easier to chase the critter down - you don't have to use ps. The most common place for the process ID to be left is /etc/named.pid. On some systems, the process ID is in /var/run/named.pid. Check the named manual page to see which directory named.pid is in on your system. Since the name server process ID is in a file, sending a HUP signal can be as simple as:

# kill -HUP `cat /etc/named.pid`

If you can't find the process ID in a file, you can always find the process ID with ps. On a BSD-based system use:

% ps -ax | grep named

On a SYS V-based system use:

% ps -ef | grep named

However, you may find more than one name server running if you use ps, since name servers spawn children to perform zone transfers. During a zone transfer, the name server pulling the zone data starts a child process, and the name server providing the zone data may start a child process. We'll digress a little here and explain why child processes are used.

A slave name server starts a child process to perform a zone transfer. This allows the slave name server to keep answering queries while the zone data is being transferred from the master server to the local disk by the child process. Once the zone is on the local disk, the slave name server reads in the new data. Using a child process to do the zone transfer fixed a problem with pre-4.8.3 versions of BIND, in which slave name servers wouldn't answer queries during a zone transfer. This could be a real nuisance on name servers that loaded lots of zones or large zones: they'd go silent for long periods of time.

A version 8 primary master name server does not spawn a child process to provide a zone to a slave name server. Instead, the primary master server transfers the zone at the same time it is answering queries. If the primary master server loads a new copy of the zone from a disk file while a zone transfer is in progress, it will abort the zone transfer in progress and load the new zone from the disk file. The slave server will have to attempt the zone transfer again after the primary master has completed loading the new zone.

A version 4 primary master name server starts a child process to provide a zone to a slave name server. This creates extra load on the host running the primary master server, especially if the zones are very large or many zone transfers are active at one time.

If the ps output shows multiple name servers, you should be able to tell easily which name server process is the parent and which processes are children. A child name server started by a slave server to pull a copy of a zone is called named-xfer instead of named:

root  548 547  0 22:03:17 ?     0:00 named-xfer -z movie.edu
      -f /usr/tmp/NsTmp0 -s 0 -P 53 192.249.249.3

A child name server started by a master name server changes its command-line options to indicate which slave server it is providing the zone to:

root 1137 1122 6 22:03:18 ?     0:00 /etc/named -zone XFR
     to [192.249.249.1]

You may encounter a version of named that doesn't change its command line, but you can still figure out the relationship between multiple named processes by examining their process IDs and parent process IDs. All the child processes will have the parent name server's process ID as their parent process ID. This may seem like stating the obvious, but only send signals to the parent name server process. The child processes will go away after the zone transfers complete.