resolv.confの変更を適切に処理するために、Linuxサーバーを再起動する必要があるのはなぜですか？
これは私の理解の欠如であるに違いないことを私は知っていますが、ここに問題があります。
最近、DNSサーバーを192.168.1.1から.2に変更したので、8つのLinuxサーバーすべてに移動し、変更を反映するように/etc/resolv.confを変更しました。それらはすべて静的であり、DHCPは関係しないことに注意してください。
変更を加えた後、nslookupとDigを使用して結果をすぐにテストできますが、すべて問題ないようです。 /etc/init.d/networking restart（ネットワークサブシステムを再起動するため）を実行し、念のため、各サーバーでApacheとpostfixを再起動しました。
数日後、私たちのWebサイトが電子メールを送信しなくなったというレポートを受け取りました。ログを調べてみると、mod_phpプロセスがdnsエントリを解決してメールを送信できないことがわかりました。頭を約30分間叩いた後、サーバーを再起動すると、すべてが正常に戻りました。
翌日、別のサーバー（通常のUbuntuではなくCentOSを使用）で、電子メールが送信されていないことを示すレポートが表示されます。ログを十分に確認すると、Postfixが名前を解決できないことがわかります。再起動すると、キューに入れられたすべてのメールがほぼ瞬時に配信されます。
だから私はここで何が欠けていますか？このプロセスのどの部分を正しく理解できなかったのですか？
おそらくnscdに噛まれたでしょう： http://linux.die.net/man/8/nscd
乾杯
ほとんどのアプリケーションは、起動時にリゾルバーを1回初期化します（res_init）、その後は二度としないでください。 pingのような寿命の短いアプリケーションでは問題になりませんが、実行時間の長いデーモンではさらに深刻になります。
（mod_phpを実行する）Apacheプロセスはおそらくその場合でした。 Apacheを再起動するだけで十分です。
resolv.confは、名前を探す場所をリゾルバーに指示します。ほとんどの場合、これはlibcリゾルバーになりますが、SPFルックアップにPython DNSリゾルバーライブラリを使用するvPostMasterなどの他のケースもあります。
したがって、[〜＃〜] could [〜＃〜]リゾルバーが長時間実行プロセスのresolv.conf情報をキャッシュしている可能性がありますが、postfixを再起動したように聞こえました。新しいresolv.confファイルの使用を開始します。
/etc/nsswitch.confをチェックして、「ホスト」に何か特別なことが起こっているかどうかを確認します。たとえば、私のラップトップのデフォルトのFedora11ラインは次のとおりです。
ホスト：ファイルmdns4_minimal [NOTFOUND = return] dns
したがって、この場合は、mdns、/ etc/hosts、およびDNSを使用します。この場合、DNSの変更が取得されていなかったとしたら、それを引き起こしているのはmdnsであるのではないかと思います。
ショーン
おそらくいくつかのキャッシュが進行中です。 sendmailでも同様の問題が発生し、サービスを再起動するだけで修正されました。
サーバーを再起動して、システム内の任意の場所にあるすべてのキャッシュをクリアする方が、キャッシュが長すぎるサービスを特定するのに時間を費やすよりも簡単な場合があります。一方、それが再び発生し、どのサービスを再起動するかがわかっている場合、それは投資であることが判明する可能性があります。