Różnica w rozpoznawaniu nazw między CentOS a Debianem

Mam mały program Java, który co sekundę zapętla wywołanie InetAddress.getByName („example.com”). Kiedy uruchamiam go na polu CentOS 6.4 za pomocą 'strace -f', widzę, że /etc/resolv.conf jest otwarty i czytam raz:

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

Kiedy uruchamiam go na Debianie 7, widzę, że plik /etc/resolv.conf jest wielokrotnie otwierany lub 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

Oba systemy mają skonfigurowane /etc/nsswitch.conf

hosts: pliki dns

Żaden system nie ma uruchomionego demona buforowania nazw.

Użyłem tej samej wersji JVM Oracle HotSot Java na obu komputerach, aby wykluczyć wszelkie różnice w Javie.

W pudełku CentOS 6.4 zainstalowano glibc 2.12. Debian 7 ma zainstalowany glibc 2.13.

Co tłumaczy odmienne zachowanie obu systemów operacyjnych w odniesieniu do otwierania i czytania /etc/resolv.conf?

debian redhat domain-name-system

— użytkownik1311618
źródło

Czy możesz proszę wkleić pełne ślady.

— Danila Ladner,

Odpowiedzi:

Programiści glibc RedHat uważają, że niektóre błędy w ich oprogramowaniu nie są błędami. Jednym z tych błędów jest ponowne czytanie resolv.conf po zmianie. glibc uważa, że to odpowiedzialność aplikacji, więc każda aplikacja będzie musiała stworzyć własną logikę.

Ponieważ jest to absolutnie szalone, programiści eglibc naprawili ten problem. Tak więc w systemach innych niż eglibc aplikacja będzie musiała mieć własną logikę ponownego inicjowania nss_dns, w przeciwnym razie konieczne będzie jej ponowne uruchomienie po zmianie resolv.conf. W systemach eglibc (Debian i rzeczy oparte na Debianie) otrzymujesz mniej błędów libc.

Dowiedzieliśmy się tego na własnej skórze po zmianie resolv.conf, wycofaniu starych serwerów DNS, a następnie ponownym uruchomieniu ponad 1200 serwerów mysql. Nie trzeba dodawać, że to nie jest zabawne.

— Dennis Kaarsemaker
źródło

Dlaczego jest to uważane za „absolutnie szalone”? I dlaczego glibc zrobił to w ten sposób?

— Michael Hampton

Ponieważ zamiast naprawiać glibc, obciążają każdą aplikację ... Co z tego, dlaczego to robią? Nie wiem Nie umiem czytać w myślach Dreppersów i nie jestem pewien, czy chcę wiedzieć, co się tam dzieje ...

— Dennis Kaarsemaker

Chodzi o to: nie jestem pewien, czy glibc jest faktycznie zepsuty. Dlaczego należy /etc/resolv.confponownie czytać przy każdym wyszukiwaniu DNS? Czy naprawdę należy się tak często zmieniać? Teraz, jeśli zachowanie nie zostało udokumentowane, wtedy mogłem zrozumieć ...

— Michael Hampton

Nie jest ono ponownie odczytywane przy każdym wyszukiwaniu, które również byłoby zepsute :) Zachowanie jest nieudokumentowane i naprawdę sprzeczne z intuicją: glibc bierze odpowiedzialność za inicjalizację biblioteki nss_dns, ale następnie nakłada na nią odpowiedzialność za ponowne zainicjowanie, nawet jeśli aplikacje te nie wiedzieć cokolwiek o nss i jak to działa. Jak to nie szaleństwo?

— Dennis Kaarsemaker

Dennis ma rację, gai w EL6 jest celowo zepsuty, ponieważ błędne

— suprjami

Nie tylko wersje bibliotek C są różne, ale CentOS używa biblioteki GNU C ( glibc), podczas gdy Debian używa Embedded GLIBC ( eglibc), więc rzeczywista implementacja wywołań systemowych wyszukiwania nazw jest zupełnie inna.

To prawdopodobnie tłumaczyłoby różne zachowanie wywołania systemowego między tymi dwiema dystrybucjami.

Zakładam, że InetAddress.getByNameprzekłada się na getaddrinfo(). Możesz zacząć od przeczytania źródła każdego wywołania systemowego w odpowiedniej implementacji i wersjach biblioteki C.

Upewnij się, że czytasz źródło z aktualnie używanych wersji pakietu. W pakietach w wersji EL 6.4 wprowadzono ponad 2-letnie udoskonalenia w porównaniu z ich oryginalnymi wersjami wcześniejszymi. Zakładam, że to samo dotyczy pakietów Debiana.

— suprjami
źródło