Unterschied bei der Namensauflösung zwischen CentOS und Debian

Unterschied bei der Namensauflösung zwischen CentOS und Debian

Ich habe ein kleines Java-Programm, das jede Sekunde InetAddress.getByName("example.com") aufruft. Wenn ich es auf einer CentOS 6.4-Box mit 'strace -f' ausführe, sehe ich, dass /etc/resolv.conf einmal geöffnet und gelesen wird:

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

Wenn ich es unter Debian 7 ausführe, sehe ich, dass /etc/resolv.conf wiederholt geöffnet oder mit stat() ausgeführt wird:

$ 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

Beide Systeme haben /etc/nsswitch.conf konfiguriert mit

Hosts: Dateien DNS

Auf keinem der Systeme wird ein Name-Caching-Daemon ausgeführt.

Ich habe auf beiden Maschinen dieselbe Version der Oracle HotSot Java JVM verwendet, um Java-Unterschiede auszuschließen.

Auf der CentOS 6.4-Box ist glibc 2.12 installiert. Auf der Debian 7-Box ist glibc 2.13 installiert.

Was ist der Grund für das unterschiedliche Verhalten der beiden Betriebssysteme beim Öffnen und Lesen von /etc/resolv.conf?

Antwort1

Die RedHat glibc-Entwickler betrachten einige Fehler in ihrer Software nicht als Fehler. Einer dieser Fehler ist das erneute Lesen von resolv.conf nach der Änderung. glibc betrachtet dies als Verantwortung der Anwendung, sodass jede einzelne Anwendung ihre eigene Logik dafür erstellen muss.

Weil das absolut verrückt ist, haben die eglibc-Entwickler dieses Problem behoben. Auf Nicht-eglibc-Systemen muss Ihre Anwendung also über eine eigene Logik zur Neuinitialisierung von nss_dns verfügen, andernfalls muss sie nach einer Änderung von resolv.conf neu gestartet werden. Auf eglibc-Systemen (Debian und auf Debian basierende Dinge) erhalten Sie eine weniger fehlerhafte libc.

Wir haben das auf die harte Tour herausgefunden, nachdem wir resolv.conf geändert, alte DNS-Server außer Betrieb genommen und dann über 1200 MySQL-Server neu starten mussten. Das ist natürlich kein Spaß.

Antwort2

Nicht nur sind die Versionen der C-Bibliothek unterschiedlich, sondern CentOS verwendet auch die GNU C-Bibliothek ( glibc), während Debian Embedded GLIBC ( eglibc) verwendet, sodass die tatsächliche Implementierung der Systemaufrufe zur Namenssuche völlig unterschiedlich ist.

Dies würde wahrscheinlich das unterschiedliche Systemaufrufverhalten dieser beiden Distributionen erklären.

Ich nehme an, dass InetAddress.getByNamesich das in übersetzen lässt getaddrinfo(). Sie könnten damit beginnen, den Quelltext jedes Systemaufrufs in der entsprechenden Implementierung und Version der C-Bibliothek zu lesen.

Stellen Sie sicher, dass Sie den Quellcode der tatsächlich von Ihnen verwendeten Paketversionen lesen. Die Pakete in EL 6.4 wurden im Vergleich zu ihren ursprünglichen Upstream-Versionen über zwei Jahre lang verbessert. Ich gehe davon aus, dass dasselbe für die Debian-Pakete gilt.

verwandte Informationen