¿Por qué se debe reiniciar un servidor Linux para manejar adecuadamente un cambio en resolv.conf?

Sé que esto tiene que ser solo una falta de comprensión, pero aquí está el problema.

Recientemente cambiamos los servidores DNS de 192.168.1.1 a .2, así que revisé los 8 servidores Linux y cambié /etc/resolv.conf para reflejar el cambio. Tenga en cuenta que todos son estáticos, no hay DHCP involucrado.

Después de hacer el cambio, puedo probar inmediatamente los resultados usando nslookup y cavar, y todo se ve bien. Hice un reinicio /etc/init.d/networking para reiniciar el subsistema de red y reinicié apache y postfix en cada uno de los servidores, solo para asegurarme.

Unos días después recibo un informe que indica que nuestros sitios web ya no envían correos electrónicos. Al leer los registros, descubrí que el proceso mod_php no podía resolver las entradas dns para enviar correo. Después de golpearme la cabeza durante unos 30 minutos, reinicié el servidor y todo volvió a la normalidad.

Al día siguiente, en un servidor diferente (usando CentOS en lugar de nuestro Ubuntu normal), recibo un informe que indica que los correos electrónicos no se están enviando, y lo suficiente como para mirar los registros indica que Postfix no puede resolver nombres. Se reinicia y entrega casi instantáneamente todo el correo en cola.

Entonces, ¿qué me estoy perdiendo aquí? ¿Qué parte de este proceso no entendí correctamente?

Probablemente te mordió nscd: http://linux.die.net/man/8/nscd

Salud

La mayoría de las aplicaciones inicializan el solucionador una vez, al inicio (con res_init), y nunca lo vuelven a hacer después. No es un problema para aplicaciones de corta duración como ping, pero es más grave para demonios de larga ejecución.

El proceso de Apache (que ejecuta mod_php) probablemente fue en ese caso. Reiniciar Apache sería suficiente.

resolv.conf dirige resolvers sobre dónde buscar nombres. En la mayoría de los casos, este será el solucionador libc, pero puede haber otros casos, como vPostMaster, que utiliza la biblioteca de resolución DNS de Python para búsquedas SPF.

Por lo tanto, PODRÍA ser que el resolutor esté almacenando en caché la información resolv.conf para procesos de larga ejecución, pero sonó como si reiniciara postfix, lo que debería haber provocado que comenzara a usar un archivo resolv.conf nuevo.

Verifique su /etc/nsswitch.conf para ver si especifica que ocurra algo especial para "hosts". Por ejemplo, la línea predeterminada de Fedora 11 en mi computadora portátil es:

hosts: archivos mdns4_minimal [NOTFOUND = return] dns

Entonces, en este caso, usa mdns, así como / etc / hosts y DNS. En este caso, si no se detectaran los cambios de DNS, me pregunto si fueron los mdns los que lo causaron.

Sean

Probablemente algo de almacenamiento en caché. Tuvimos un problema similar sendmaily solo reiniciamos el servicio.

A veces es más fácil reiniciar el servidor y borrar todas esas cachés en cualquier parte del sistema que pasar todo ese tiempo identificando qué servicio está almacenando en caché durante demasiado tiempo. Por otro lado, puede llegar a ser una inversión cuando ocurre nuevamente y usted sabe qué servicio reiniciar.