djbdns の各サービスは daemontools の supervise に見張られて動いているため、再起動は kill ではなく svc -t /service/サービス名 で行います。また、tinydns のレコード変更は data.cdb を作り直すだけで反映され、再起動は要りません。この記事では、再起動が必要な変更と不要な変更の見分け方、svc と svstat の使い方、再起動後の確認、再起動がうまくいかないときの切り分けを説明します。
djbdns 本体は 1.05 以降の公式な更新がなく、各ディストリビューションのパッチ版や派生版で使われ続けています（2026年10月現在）。パッケージや導入方法によってサービスの置き場所（/service や /etc/service など）が異なるので、以下のパスは手元の環境に読み替えてください。
再起動が必要な変更と、不要な変更
最初に、本当に再起動が必要かを判断します。djbdns は「データの変更は再起動なしで反映される」作りになっているため、不要な再起動を減らせます。
再起動が不要なもの
- tinydns のレコード変更：
root/dataを編集してmake（内部でtinydns-data）を実行すると、data.cdb が新しいファイルに置き換わります。tinydns は問い合わせのたびに data.cdb を開くので、次の問い合わせから新しい内容で答えます。 - axfrdns の許可ルール変更：
tcpファイルを編集してmakeを実行すると tcp.cdb が作り直され、tcpserver は接続ごとにこのルールを参照します。 - dnscache の問い合わせ元の追加：
root/ip/にネットワークの名前のファイル（例：root/ip/192.168.1）を作る方式で、多くの環境では再起動なしで受け付けるようになります。
再起動が必要なもの
env/以下の環境変数（IP・ROOT・CACHESIZE・DATALIMITなど）の変更。これらは起動時にしか読まれません。- dnscache の
root/servers/の変更（ルートサーバーや転送先の一覧）。 - dnscache のキャッシュを空にしたいとき。キャッシュはメモリ上にしかないため、再起動で消えます。
- バイナリの入れ替え（パッケージ更新など）の後。
「レコードを直したのに古い答えが返る」という理由で tinydns を再起動しても、多くの場合は解決しません。その場合は、make が成功しているか、問い合わせ先のキャッシュサーバーに古い答えが残っていないかを先に確認します。
svstat で現在の状態を確認する
再起動の前に、対象のサービスと、そのログ用サービスの状態を見ます。
svstat /service/tinydns /service/tinydns/log
svstat /service/dnscache /service/dnscache/logup (pid 1234) 86400 seconds のように表示されれば、そのプロセスが 86400 秒動き続けているという意味です。再起動後にこの秒数が小さくなっていれば、再起動できたと判断できます。supervise not running と出る場合は、サービスそのものではなく、それを見張る svscan 側が動いていません（後述）。
svc で再起動する
daemontools の svc コマンドで supervise に指示を出します。よく使うオプションは次のとおりです。
-t：TERM シグナルを送ります。サービスが「動いているべき状態」なら、supervise がすぐに起動し直します。通常の再起動はこれで足ります。-d：停止し、自動での再起動もさせません。-u：起動し、落ちたら起動し直す状態に戻します。-h：HUP シグナルを送ります。tinydns や dnscache は HUP で設定を読み直す作りではないため、再起動の代わりにはなりません。
# tinydns を再起動
svc -t /service/tinydns
# dnscache を再起動（キャッシュが消える）
svc -t /service/dnscache
# 状態を確認（秒数が小さくなっていればよい）
svstat /service/tinydns /service/dnscache設定を大きく変えるときは、svc -d で止めてから変更し、svc -u で起動すると、変更途中の状態で起動し直されるのを避けられます。ただし止めている間は問い合わせに答えないため、権威サーバーなら複数台あるうちの1台ずつ作業します。
kill でプロセスを直接止めても supervise がすぐに起動し直すので、結果としては再起動になります。しかし、どの PID に何を送ったかが分かりにくくなるため、svc を使うほうが安全です。svc -k（KILL）は、TERM で止まらないときの最後の手段にとどめます。
dnscache を再起動するときの注意
dnscache を再起動するとキャッシュが空になり、しばらくは外部への問い合わせが増えて応答が遅くなります。社内の多くの端末が使っているリゾルバーなら、利用が少ない時間帯を選びます。CACHESIZE を変える場合は、DATALIMIT がそれより十分大きくないと起動できないことがあるため、両方を合わせて見直します。
再起動後に確認すること
再起動したら、状態・ログ・実際の応答の3点を確認します。
# 1. 状態
svstat /service/tinydns
# 2. ログ（タイムスタンプを読める形に変換）
tai64nlocal < /service/tinydns/log/main/current | tail -n 20
# 3. 実際の応答（権威サーバーには再帰なしで問い合わせる）
dig @192.0.2.1 example.com SOA +norec
dig @127.0.0.1 www.example.com A # dnscache の場合ログは multilog が log/main/current に書き出しており、行頭の @4000... は TAI64N 形式の時刻です。tai64nlocal を通すとローカル時刻で読めます。tinydns のログには問い合わせ1件ごとの記録が出るので、再起動の後に新しい行が出ていれば、問い合わせを受け付けています。
再起動がうまくいかないときの切り分け
起きやすい順に並べます。
- 起動と終了を繰り返している：
svstatを数秒おきに実行しても秒数が 0〜1 のままなら、起動直後に落ちています。ログの最後の行を見ます。unable to bindのような内容なら、env/IPのアドレスがそのサーバーに存在しないか、ほかのプログラムが 53 番ポートを使っています。ss -lunp | grep ':53 'で確かめます。systemd-resolved が127.0.0.53で待ち受けている環境では、dnscache を0.0.0.0で待ち受けさせると衝突します。 - **
supervise not runningと表示される**：svscan が動いていないか、サービスのディレクトリが svscan の見張り対象（/serviceなど）にリンクされていません。ls -l /service/でシンボリックリンクを確認し、svscan 自体は systemd の daemontools 用ユニットなど、環境の起動方法で立ち上げ直します。ユニット名はパッケージによって異なります。 - **
svc -uしても起動しない、または起動後に自動で起動しない**：サービスのディレクトリにdownというファイルがあると、svscan の起動時にそのサービスは止まったままになります。意図して置いたものでなければ削除します。 - 起動はするが答えない：tinydns なら
root/data.cdbが存在するか、makeがエラーなく終わったかを確認します。dnscache なら、問い合わせ元のネットワークがroot/ip/に登録されているかを確認します。 - 権限のエラー：
env/UID・env/GIDのユーザーが data.cdb を読めない、ログのディレクトリに書けない、といった場合です。導入時にユーザーを作り直した後などに起きます。
まとめ
- tinydns のレコード変更は
makeで data.cdb を作り直せば反映され、再起動は要りません。環境変数・dnscache の転送先の変更・キャッシュの消去には再起動が必要です。 - 再起動は
svc -t /service/サービス名で行い、svstatの秒数で再起動できたかを確かめます。HUP では設定は読み直されません。 - 再起動後は、状態・
tai64nlocalで読んだログ・digでの応答の3点を確認します。 - 起動と終了を繰り返すときは、ログの最後の行から、アドレス・ポートの衝突、
downファイル、data.cdb や権限の問題を順に確認します。