Perché un server Linux deve essere riavviato per gestire correttamente una modifica in resolv.conf?

So che questo deve essere solo una mancanza della mia comprensione, ma ecco il problema.

Di recente abbiamo cambiato i server DNS da 192.168.1.1 a .2, quindi sono andato in giro per tutti e 8 i miei server Linux e ho cambiato /etc/resolv.conf per riflettere il cambiamento. Si noti che sono tutti statici, non è coinvolto DHCP.

Dopo aver apportato la modifica, posso testare immediatamente i risultati usando nslookup e scavare, e tutto sembra a posto. Ho fatto un riavvio /etc/init.d/networking - per riavviare il sottosistema di rete - e ho riavviato apache e postfix su ciascuno dei server, per essere sicuro.

Pochi giorni dopo ricevo un rapporto che afferma che i nostri siti Web non inviano più e-mail. Esaminando i registri ho scoperto che il processo mod_php non è riuscito a risolvere le voci DNS per l'invio di posta. Dopo aver battuto la testa per circa 30 minuti, ho riavviato il server e tutto è tornato alla normalità.

Il giorno successivo su un server diverso (usando CentOS anziché la nostra normale Ubuntu), ricevo un rapporto in cui si afferma che le e-mail non stanno attraversando, e sicuramente guardando i registri indica che Postfix non è in grado di risolvere i nomi. Riavviato e consegna quasi istantaneamente tutta la posta in coda.

Quindi cosa mi sto perdendo qui? Quale parte di questo processo non ho capito correttamente?

Probabilmente sei stato morso da nscd: http://linux.die.net/man/8/nscd

Saluti

La maggior parte delle applicazioni inizializzano il resolver una volta, all'avvio (con res_init), e non lo fanno mai più in seguito. Non è un problema per applicazioni di breve durata come il ping, ma più grave per i demoni di lunga durata.

Il processo Apache (che esegue mod_php) era probabilmente in quel caso. Riavviare Apache sarebbe sufficiente.

resolv.conf indirizza i resolver su dove cercare i nomi. Nella maggior parte dei casi, questo sarà il risolutore libc, ma potrebbero esserci altri casi come vPostMaster che utilizza la libreria del risolutore DNS Python per le ricerche SPF.

Quindi, POTREBBE essere che il resolver sta memorizzando nella cache le informazioni resolv.conf per processi a esecuzione prolungata, ma sembrava che avessi riavviato postfix, il che avrebbe dovuto far sì che iniziasse a utilizzare un nuovo file resolv.conf.

Controlla il tuo /etc/nsswitch.conf per vedere se specifica qualcosa di speciale accadendo per "host". Ad esempio, la linea Fedora 11 predefinita sul mio laptop è:

host: file mdns4_minimal [NOTFOUND = return] dns

Quindi in questo caso usa mdns, / etc / hosts e DNS. In questo caso, se le modifiche DNS non fossero state rilevate, mi chiedevo se fossero state le mdns a causarle.

Sean

Probabilmente sta succedendo un po 'di cache. Abbiamo riscontrato un problema simile sendmaile il riavvio del servizio ha risolto il problema.

A volte è più semplice riavviare il server e cancellare tutte quelle cache in qualsiasi punto del sistema piuttosto che passare tutto il tempo a identificare quale servizio sta memorizzando nella cache troppo a lungo. D'altra parte, può rivelarsi un investimento quando si ripete e sai quale servizio riavviare.