Differenza di risoluzione dei nomi tra CentOS e Debian

Ho un piccolo programma Java che esegue il loop chiamando InetAddress.getByName ("esempio.com") ogni secondo. Quando lo eseguo su un box CentOS 6.4 usando 'strace -f' vedo che /etc/resolv.conf viene aperto e letto una volta:

$ grep /etc/resolv.conf strace.out
[pid 24810] open("/etc/resolv.conf", O_RDONLY) = 6

Quando lo eseguo su Debian 7 vedo che /etc/resolv.conf viene ripetutamente aperto o stat () 'd:

$ grep  /etc/resolv.conf strace.out
[pid 41821] open("/etc/resolv.conf", O_RDONLY) = 10
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0
[pid 41821] open("/etc/resolv.conf", O_RDONLY) = 10
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0
[pid 41821] stat("/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=92, ...}) = 0

Entrambi i sistemi hanno /etc/nsswitch.conf configurato con

host: file dns

Nessuno dei due sistemi ha un demone di memorizzazione nella cache dei nomi in esecuzione.

Ho usato la stessa versione di Oracle HotSot Java JVM su entrambe le macchine per escludere eventuali differenze Java.

Nella confezione di CentOS 6.4 è installato glibc 2.12. Il box Debian 7 ha glibc 2.13 installato.

Cosa spiega il diverso comportamento tra i due sistemi operativi per quanto riguarda l'apertura e la lettura /etc/resolv.conf?

debian redhat domain-name-system

— user1311618
fonte

Puoi per favore incollare tracce complete.

— Danila Ladner,

Risposte:

Gli sviluppatori di RedHat glibc considerano alcuni bug nel loro software come non bug. Uno di questi bug è la rilettura di resolv.conf dopo la modifica. glibc ritiene che la responsabilità dell'applicazione, quindi ogni singola applicazione dovrà creare la propria logica per questo.

Perché questo è assolutamente disastroso, gli sviluppatori eglibc hanno risolto questo problema. Quindi su sistemi non-eglibc l'applicazione dovrà avere la propria logica per reinizializzare nss_dns, altrimenti dovrà essere riavviata dopo una modifica resolv.conf. Sui sistemi eglibc (Debian e cose basate su Debian), ottieni una libc meno buggy.

Lo abbiamo scoperto nel modo più duro dopo aver modificato resolv.conf, aver rimosso le autorizzazioni dai vecchi server DNS e aver quindi dovuto riavviare oltre 1200 server mysql. Inutile dire che non è divertente.

— Dennis Kaarsemaker
fonte

Perché questo è considerato "assolutamente fuori di testa"? E perché glibc l'ha fatto in questo modo?

— Michael Hampton

Perché invece di riparare glibc, pongono l'onere su ogni applicazione là fuori ... Come mai perché lo fanno? Non lo so. Non riesco a leggere la mente di Dreppers e non sono sicuro di voler sapere cosa succede lì dentro ...

— Dennis Kaarsemaker,

Il fatto è: non sono sicuro che glibc sia effettivamente rotto. Perché deve /etc/resolv.confessere riletto ad ogni ricerca DNS? Si prevede davvero che cambi frequentemente? Ora, se il comportamento non fosse documentato, allora potrei capire ...

— Michael Hampton

Non viene riletto ad ogni ricerca, anche quello verrebbe interrotto :) Il comportamento non è documentato e è davvero controintuitivo: glibc si assume la responsabilità di inizializzare la libreria nss_dns, ma successivamente rende l'applicazione responsabile per reinizializzarla, anche se quelle applicazioni non lo fanno sapere comunque di nss e come funziona. In che modo non è scemo?

— Dennis Kaarsemaker,

Dennis ha ragione, il gai in EL6 è intenzionalmente interrotto perché il comportamento errato è diventato il "comportamento previsto" - access.redhat.com/site/solutions/541163

— suprjami

Non solo le versioni della libreria C sono diverse, ma CentOS utilizza la libreria GNU C ( glibc) mentre Debian utilizza Embedded GLIBC ( eglibc), quindi l'implementazione effettiva delle chiamate del sistema di ricerca dei nomi è completamente diversa.

Ciò spiegherebbe probabilmente il diverso comportamento delle chiamate di sistema tra queste due distribuzioni.

Presumo si InetAddress.getByNametraduca in getaddrinfo(). È possibile iniziare leggendo l'origine di ogni syscall nella relativa implementazione e versione della libreria C.

Assicurati di leggere l'origine dalle versioni del pacchetto che stai utilizzando. I pacchetti in EL 6.4 hanno subito oltre 2 anni di miglioramenti rispetto alle loro versioni originali a monte. Presumo che lo stesso vale per i pacchetti Debian.

— suprjami
fonte