2026年6月5日

nscd の確認手順｜動いているか・何をキャッシュしているか・どのプロセスが使っているかを点検する

DNS・名前解決

サーバーで nscd が使われているかどうかは、パッケージの有無、サービスの状態、/etc/nscd.conf の設定、sudo nscd -g の統計、ソケットへの接続の5点を見れば把握できます。引き継いだサーバーや、名前解決やユーザー情報の挙動に違和感があるサーバーで、「nscd がいるのか、何をしているのか、残すべきか」を判断するための点検手順をまとめました。障害が起きている最中の対処や、TTLの値の決め方は別の話題になるので、ここでは現状を正しく把握することに絞ります。

nscd とは何をするものか

nscd（Name Service Cache Daemon）は、glibcに付属するキャッシュ用のデーモンです。ホスト名の解決（hosts）だけでなく、ユーザー（passwd）、グループ（group）、サービス名（services）、netgroup などの問い合わせ結果をキャッシュします。LDAPなどでユーザー情報を外部から引いている環境では、ログインやファイル一覧の表示を速くする目的で使われてきました。

nscd が動いていると、glibcの名前解決関数は /etc/nsswitch.conf に書かれた参照先より先に、nscd へ問い合わせます。そのため nsswitch.conf には nscd の名前は出てきません。設定ファイルを眺めるだけでは存在に気づきにくい点が、点検が必要になる理由です。

手順1：インストールされているか

まずパッケージの有無を確認します。

command -v nscd
# Debian・Ubuntu系
dpkg -l nscd
# RHEL・Fedora系
rpm -q nscd

何も見つからなければ、そのサーバーでは nscd は使われていません。最近の多くのディストリビューションでは標準ではインストールされず、近年は非推奨扱いとして systemd-resolved や SSSD を案内しているものもあります（2026年10月現在）。古い構成を引き継いだサーバーや、LDAP連携のために後から入れたサーバーで見つかることが多いです。

手順2：サービスが動いているか、起動時に有効か

インストールされていても、動いているとは限りません。

systemctl status nscd --no-pager
systemctl is-enabled nscd

Active: active (running) なら動作中です。is-enabled が enabled なら、再起動後も自動で起動します。「止めたつもりが、再起動で復活していた」ということがあるので、両方を見ておきます。直近のログも合わせて確認すると、繰り返し再起動していないか、エラーが出ていないかが分かります。

journalctl -u nscd -n 50 --no-pager

手順3：何をキャッシュする設定か

/etc/nscd.conf で、どのデータベースのキャッシュが有効かを確認します。

grep -E '^\s*enable-cache' /etc/nscd.conf

enable-cache hosts yes ならホスト名、enable-cache passwd yes ならユーザー情報をキャッシュしています。ここで点検したいのは、「その環境で本当にキャッシュが必要なデータベースだけが有効か」です。たとえばWebサーバーでユーザー情報はローカルの /etc/passwd だけなら、passwd のキャッシュはほとんど意味がありません。逆に hosts のキャッシュは、外部APIの接続先が変わったときに古い結果を残す原因になり得ます。

保持時間（positive-time-to-live・negative-time-to-live）、ディスクへの保存（persistent）、/etc/hosts などの変更検知（check-files）もこのファイルで決まります。値の妥当性の判断は、TTLの確認手順として別途行うとよいでしょう。

手順4：統計情報で実際の動きを見る

設定だけでなく、実際にどれくらい使われているかを統計で確認します。

sudo nscd -g

データベースごとに欄が分かれて表示されます。hosts の欄の例は次のとおりです（一部抜粋、数値は例、表記はバージョンにより異なります）。

hosts cache:

            yes  cache is enabled
            yes  cache is persistent
            yes  cache is shared
           3600  seconds time to live for positive entries
             20  seconds time to live for negative entries
          15230  cache hits on positive entries
            412  cache hits on negative entries
           1180  cache misses on positive entries
             95  cache misses on negative entries
             92% cache hit rate
             38  current number of cached values
            yes  check /etc/hosts for changes

読むときのポイントは次の3つです。

cache hit rate が低い、またはヒット数がほとんど増えないなら、そのデータベースのキャッシュはあまり役に立っていません
cache hits on negative entries が多いなら、失敗した結果を何度も返しています。存在しない名前を繰り返し引いているアプリがないか、一時的な障害の結果が残っていないかを疑います
current number of cached values で、いま何件覚えているかが分かります

統計は nscd の再起動でリセットされます。比較するときは、稼働時間（systemctl status の起動時刻）も一緒に記録しておくと判断しやすくなります。一般ユーザーで実行すると拒否される場合があるため、sudo を付けてください。

手順5：どのプロセスが nscd を使っているか

nscd はUNIXドメインソケット（多くの環境で /var/run/nscd/socket または /run/nscd/socket）で問い合わせを受けます。ソケットがあるか、問い合わせのときに実際に接続しているかを確認します。

ls -l /var/run/nscd/socket /run/nscd/socket 2>/dev/null
sudo strace -f -e trace=connect getent hosts www.example.com 2>&1 | grep nscd

2行目で nscd/socket への connect が表示されれば、glibcを使うプログラムは nscd を経由しています。ただし、次のものは nscd を通りません。名前解決の結果が食い違ったとき、この違いを知っていると切り分けが早くなります。

dig、nslookup、host などのDNS調査ツール（自前でDNSに問い合わせる）
Go言語で作られた一部のプログラム（設定やビルドによって、独自の名前解決を使う）
Alpine LinuxなどmuslベースのOSやコンテナ（muslは nscd に対応していない）
ホストとソケットを共有していないDockerコンテナ（コンテナ内に nscd がなければ使われない）

PHPやNode.js、Pythonなど一般的な言語の標準的な名前解決は、glibc上で動いていれば nscd を経由します。WordPressの外部通信も、ホストに直接PHPを入れている構成なら通常は nscd の影響を受けます。

手順6：ほかのキャッシュと重なっていないか

最後に、同じ役割のサービスが並んで動いていないかを確認します。

systemctl is-active nscd systemd-resolved sssd dnsmasq
grep -E '^(hosts|passwd|group):' /etc/nsswitch.conf

nscd と systemd-resolved が両方動いていれば、ホスト名のキャッシュが二重になります。nscd と SSSD が両方動いている場合、SSSDの文書では passwd・group などを nscd でキャッシュしないよう案内されています。重なりが見つかったら、どちらか一方に役割を寄せる方向で整理するのが一般的です。

点検結果から判断する

点検の結果は、次のように判断の材料にします。

必要なキャッシュだけが有効で、ヒット率も高い：そのまま運用。設定ファイルの内容と点検日を運用メモに残す
hosts のキャッシュは有効だが、ヒット率が低い、またはほかのキャッシュと重複している：enable-cache hosts no にしてホスト名のキャッシュだけ外すことを検討する
どのキャッシュもほとんど使われていない：サービスを止めて様子を見たうえで、systemctl disable nscd で無効化を検討する

設定を変える前には sudo cp /etc/nscd.conf /etc/nscd.conf.bak のようにバックアップを取り、可能ならステージング環境で動作を確かめてから本番に反映してください。nscd を止めても、glibcは nscd を使わない通常の問い合わせに切り替わるため、名前解決やログインが止まることは基本的にありません。ただし、LDAPなど外部のユーザー情報を使っている環境では、応答速度が変わる可能性があります。

まとめ

nscd は nsswitch.conf に名前が出ないため、パッケージ・サービス・設定・統計・ソケットの5点で存在と役割を確認する
sudo nscd -g でデータベースごとのヒット率やネガティブキャッシュの利用状況が分かる
strace でソケットへの接続を見ると、どのプログラムが nscd を通っているかを確かめられる
dig、muslベースの環境、一部のGoプログラムなどは nscd を通らない
ほかのキャッシュと重なっていれば役割を整理し、変更前にはバックアップを取る