Pourquoi un serveur Linux doit-il être redémarré pour gérer correctement un changement dans resolv.conf?

Je sais que cela doit juste être un manque de compréhension, mais voici le problème.

Nous avons récemment changé les serveurs DNS de 192.168.1.1 à .2, j'ai donc parcouru les 8 serveurs Linux et changé /etc/resolv.conf pour refléter le changement. Notez qu'ils sont tous statiques, aucun DHCP n'est impliqué.

Après avoir fait le changement, je peux immédiatement tester les résultats en utilisant nslookup et dig, et tout semble bon. J'ai fait un redémarrage /etc/init.d/networking - pour redémarrer le sous-système réseau - et redémarré apache et postfix sur chacun des serveurs, juste pour être sûr.

Quelques jours plus tard, je reçois un rapport indiquant que nos sites Web n'envoient plus d'e-mails. En parcourant les journaux, j'ai trouvé que le processus mod_php ne pouvait pas résoudre les entrées DNS pour envoyer du courrier. Après avoir frappé ma tête dessus pendant environ 30 minutes, j'ai redémarré le serveur et tout est revenu à la normale.

Le lendemain, sur un autre serveur (en utilisant CentOS plutôt que notre Ubuntu normal), je reçois un rapport indiquant que les e-mails ne passent pas, et bien sûr, la lecture des journaux indique que Postfix ne peut pas résoudre les noms. Redémarré et il délivre presque instantanément tout le courrier en file d'attente.

Alors qu'est-ce que je manque ici? Quelle partie de ce processus ai-je échoué à comprendre correctement?

Vous avez probablement été mordu par nscd: http://linux.die.net/man/8/nscd

À votre santé

La plupart des applications initialisent le résolveur une fois, au démarrage (avec res_init), et ne le refont plus jamais par la suite. Ce n'est pas un problème pour les applications de courte durée comme le ping, mais plus grave pour les démons de longue durée.

Le processus Apache (qui exécute mod_php) était probablement dans ce cas. Redémarrer Apache aurait suffi.

resolv.conf indique aux résolveurs où rechercher les noms. Dans la plupart des cas, ce sera le résolveur libc, mais il peut y avoir d'autres cas tels que vPostMaster qui utilise la bibliothèque de résolveur DNS Python pour les recherches SPF.

Ainsi, il POURRAIT être que le résolveur mette en cache les informations resolv.conf pour les processus de longue durée, mais cela sonnait comme si vous redémarriez postfix, ce qui aurait dû le faire commencer à utiliser un nouveau fichier resolv.conf.

Vérifiez votre /etc/nsswitch.conf pour voir s'il spécifie quelque chose de spécial qui se passe pour les "hôtes". Par exemple, la ligne Fedora 11 par défaut sur mon ordinateur portable est:

hôtes: fichiers mdns4_minimal [NOTFOUND = return] dns

Donc, dans ce cas, il utilise mdns ainsi que / etc / hosts et DNS. Dans ce cas, si les modifications DNS n'étaient pas détectées, je me demande si ce sont les mdns qui en sont la cause.

Sean

Probablement une mise en cache en cours. Nous avons eu un problème similaire sendmailet le redémarrage du service l'a corrigé.

Parfois, il est plus facile de simplement redémarrer le serveur et d'effacer tous ces caches n'importe où dans le système que de passer tout ce temps à identifier le service qui met en cache trop longtemps. D'un autre côté, cela peut s'avérer être un investissement lorsqu'il se reproduit et que vous savez quel service redémarrer.