Differenza di risoluzione dei nomi tra CentOS e Debian

Ho un piccolo programma Java che richiama InetAddress.getByName ("example.com") each secondo. Quando l'ho eseguito su una casella di CentOS 6.4 usando 'strace -f' vedo che /etc/resolv.conf viene aperto e letto una sola volta:

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

Quando l'ho eseguito su Debian 7 vedo che /etc/resolv.conf viene aperto più volte oppure 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 sisthemes hanno /etc/nsswitch.conf configurato con

host: file dns

Né il sistema ha un demone di cache di nome in esecuzione.

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

La casella CentOS 6.4 ha glibc 2.12 installato. La casella Debian 7 ha glibc 2.13 installato.

Che cosa rappresenta il diverso comportmento tra i due sisthemes operativi per quanto riguarda l'apertura e la lettura di /etc/resolv.conf?

  • fare rumore su redhat quando il command è terminato
  • Infiniband switchless tra due server su RHEL 6.3
  • Distriggersre il login locale root, consentire il login root su ssh
  • Rysnc Dynamic Nome file di log
  • Script per eliminare i file più vecchi di 30 giorni
  • svnserve sembra scrivere i file come root. Come posso dare accesso allo stesso repository tramite svnserve e apache?
  • Perdita di pacchetti UDP in migrazione da RHEL 5.7 a RHEL 6.8
  • Come posso installare i pacchetti dal canale opzionale RHEL6 tramite Kickstart?
  • 2 Solutions collect form web for “Differenza di risoluzione dei nomi tra CentOS e Debian”

    Gli sviluppatori di gli utenti di RedHat considerano alcuni bug nel loro software per non essere bug. Uno di questi bug è la rilettura di resolv.conf dopo la modifica. Glibc ritiene che la responsabilità dell'applicazione, quindi each applicazione deve creare la propria logica per questo.

    Poiché questo è assolutamente bonkers, gli sviluppatori di eglibc hanno risolto questo problema. Quindi sui sisthemes non-eglibc la tua applicazione dovrà avere la propria logica per reinizializzare nss_dns, altrimenti dovrà essere riavviato dopo un cambiamento resolv.conf. Sui sisthemes eglibc (Debian e le cose basate su Debian), si ottiene un libc less buggy.

    Abbiamo trovato questo in modo duro dopo aver cambiato resolv.conf, distriggersndo vecchi server DNS e quindi wherendo riavviare server 1200+ mysql. Inutile dire che questo non è divertente.

    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'effettiva implementazione delle chiamate di sistema di ricerca di nomi è completamente diversa.

    Questo potrebbe probabilmente rappresentare un diverso comportmento delle chiamate di sistema tra queste due distribuzioni.

    Suppongo che InetAddress.getByName traduce in getaddrinfo() . È ansible iniziare a leggere la fonte di ciascun syscall nella relativa implementazione e nelle versioni della libreria C.

    Assicurati di leggere l'origine dalle versioni del pacchetto effettivo che utilizzi. I pacchetti in EL 6.4 hanno avuto più di 2 anni di miglioramenti rispetto alle versioni originali a monte. Suppongo che lo stesso vale per i pacchetti Debian.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.