2026年6月9日

djbdns を再起動する手順｜OS 再起動後の自動起動・svscan ごとの再起動・複数台を順番に再起動する方法

DNS・名前解決

djbdns（tinydns・dnscache・axfrdns）の個々のサービスは svc -t で再起動できますが、OS ごと再起動したときや、daemontools の svscan そのものを立ち上げ直すときは、別の点に気をつける必要があります。OS の起動時に svscan が自動で立ち上がる設定になっていなければ、再起動の後に DNS が止まったままになるためです。この記事では、OS 再起動の前に確認すること、svscan を systemd から起動する設定、svscan ごとの再起動、複数台の権威DNSを1台ずつ再起動する手順を説明します。

個々のサービスの svc -t による再起動と、再起動が要らない変更の見分け方は、別の記事で扱っています。ここでは「サーバーや監視の仕組みごと再起動する場面」に絞ります。djbdns 本体は 1.05 以降の公式な更新がなく、パッケージや導入方法によってファイルの置き場所が異なります（2026年10月現在）。以下の /etc/service や /usr/bin のパスは手元の環境に読み替えてください。

djbdns が動く仕組みを押さえる

再起動の手順を考える前に、どのプロセスが何を起動しているかを確認しておきます。

svscan：サービスのディレクトリ（/etc/service や /service）を見張り、そこにあるサービスごとに supervise を起動します。
supervise：1つのサービスを見張り、落ちたら起動し直します。tinydns と、そのログ用の multilog のそれぞれに1つずつあります。
svscanboot：svscan を起動し、出力を readproctitle に渡すための小さなスクリプトです。

つまり、OS の起動時に svscan（または svscanboot）が起動すれば、あとは連鎖的にすべてのサービスが立ち上がります。逆に svscan が起動しなければ、tinydns も dnscache も起動しません。

# 動いているプロセスの親子関係を確認する
ps -ef --forest | grep -E 'svscan|supervise|tinydns|dnscache|multilog' | grep -v grep

OS を再起動する前に確認すること

OS の再起動の前に、次の3点を確認しておくと、再起動後に止まったままになる事故を防げます。

svscan を起動する仕組みが有効か：systemd の環境なら、svscan を起動するユニットが有効（enabled）になっているかを見ます。ユニット名はパッケージによって異なり、Debian 系の daemontools-run では daemontools という名前のことが多いです。systemctl list-unit-files | grep -iE 'daemontools|svscan' で探します。ソースから daemontools を入れ、/etc/inittab や rc.local に追記する古い手順で起動している場合、今の systemd 環境では働かないことがあります。
待ち受けアドレスが起動時に付くか：env/IP に書いたアドレスが、OS の起動時に自動で付く設定になっているかを確認します。手動で追加したセカンダリアドレスは、再起動で消えることがあります。
ポートを取り合うサービスがないか：OS の更新で systemd-resolved が有効になった、などの理由で、53番ポートを別のサービスが先に取ることがあります。ss -lunp | grep ':53 ' で、今どのプロセスが待ち受けているかを控えておきます。

svscan を systemd から起動する

svscan を起動するユニットが見当たらない場合は、自分で用意します。以下は、/usr/bin/svscanboot がある環境の例です。ソースから入れた場合は /command/svscanboot などになるので、command -v svscanboot で場所を確かめてから書き換えてください。

# /etc/systemd/system/svscan.service
[Unit]
Description=daemontools svscan
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/bin/svscanboot
Restart=always
RestartSec=5s

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now svscan.service
systemctl status svscan.service --no-pager

svscanboot が見張るディレクトリは、ビルドやパッケージの設定で決まっています（ソースからの既定は /service）。サービスのリンクを置いたディレクトリと一致しているかを確認します。

すでにパッケージのユニットや inittab で svscan が動いている状態で、このユニットも有効にすると、svscan が2つ起動します。同じサービスを2つの supervise が見張ろうとしてエラーが出るので、起動の仕組みは1つにまとめます。

After=network-online.target を入れているのは、tinydns が待ち受けるアドレスが付く前に起動するのを減らすためです。仮にアドレスが付く前に起動して失敗しても、supervise が繰り返し起動し直すため、アドレスが付いた時点で動き始めます。

svscan ごと再起動する

daemontools の更新の後や、svscan 自体の動作がおかしいときは、svscan ごと再起動します。上のユニットで起動している場合、既定の動作ではユニットの停止で svscan・supervise・各サービスがまとめて止まり、起動でまとめて立ち上がります。

sudo systemctl restart svscan.service
sleep 5
sudo svstat /etc/service/*
sudo svstat /etc/service/*/log

svscan を止めずに全サービスだけを再起動したいときは、svc -t をまとめて実行します。

sudo svc -t /etc/service/*

ログ用の multilog は、サービス本体と一緒には再起動されません。ログが書かれないなどの理由でログ側も再起動したいときは、svc -t /etc/service/tinydns/log のように別に指定します。

OS 再起動後の確認

OS を再起動したら、プロセス・待ち受け・応答・ログの順に確認します。

# 1. svscan と各サービスの状態
pgrep -a svscan
sudo svstat /etc/service/*

# 2. 53番ポートの待ち受け
ss -lunp | grep ':53 '
ss -ltnp | grep ':53 '   # axfrdns を使っている場合

# 3. 応答
dig @192.0.2.53 example.com SOA +norec   # tinydns
dig @127.0.0.1 example.org A            # dnscache

# 4. ログ
sudo tai64nlocal < /etc/service/tinydns/log/main/current | tail -n 20

svstat の秒数が数秒のまま増えない（起動と終了を繰り返している）場合は、ログの最後の行を見ます。アドレスにバインドできない旨の内容なら、手順の前に確認した「待ち受けアドレス」か「ポートの取り合い」が原因です。

dnscache は再起動でキャッシュが空になるため、再起動の直後は外部への問い合わせが増え、しばらく応答が遅くなります。社内のリゾルバーとして使っているなら、利用の少ない時間帯に再起動します。

複数台の権威DNSを順番に再起動する

権威DNSを2台以上で運用しているなら、同時に再起動せず、1台ずつ再起動して確認してから次に進みます。

再起動する前に、全台の data.cdb が同じ内容かを確かめます。ゾーンを rsync などで配っているなら、配布が終わっているかを確認します。簡単な確認として、各サーバーに SOA を問い合わせ、シリアルが一致しているかを見ます。
1台目を再起動し、上の「OS 再起動後の確認」を行います。
1台目が外部から正しく答えることを、別のネットワークから dig @1台目のアドレス で確かめてから、2台目に進みます。

# 全台の SOA シリアルを比べる
for ns in 192.0.2.53 198.51.100.53; do
  echo -n "$ns: "
  dig @"$ns" example.com SOA +norec +short
done

再起動中の1台が答えなくても、問い合わせ側のリゾルバーは別の NS に問い合わせ直すため、利用者への影響は小さくなります。ただし、全台が同じデータセンターや同じ更新の対象にあると、同時に止まりやすくなります。OS の自動更新と自動再起動を有効にしている場合は、台ごとに実行の時間をずらしておきます。

まとめ

djbdns は svscan → supervise → 各サービスの順で起動するため、OS 再起動後に svscan が自動で立ち上がるかが要点です。systemd の環境では、svscan を起動するユニットが有効になっているかを先に確認します。
OS 再起動の前に、起動の仕組み・待ち受けアドレス・53番ポートの取り合いの3点を確認しておくと、止まったままになる事故を防げます。
svscan ごとの再起動はユニットの再起動で、全サービスだけなら svc -t /etc/service/* で行います。ログ側は別に再起動します。
複数台の権威DNSは、SOA シリアルの一致を確かめてから1台ずつ再起動し、外部からの応答を確認して次に進みます。