Різниця в роздільній здатності імен між CentOS і Debian

У мене є невеличка програма Java, яка щосекунди викликує InetAddress.getByName ("example.com"). Коли я запускаю його на вікні CentOS 6.4, використовуючи 'strace -f', я бачу, що /etc/resolv.conf відкривається і читається один раз:

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

Коли я запускаю його на Debian 7, я бачу, що /etc/resolv.conf повторно відкривається або 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

В обох системах налаштовано /etc/nsswitch.conf

хости: файли dns

Жодна система не має демона кешування імен.

Я використовував одну і ту ж версію Oracle HotSot Java JVM на обох машинах, щоб виключити будь-які відмінності Java.

У вікні CentOS 6.4 встановлено glibc 2.12. У вікні Debian 7 встановлено glibc 2.13.

Що пояснює різну поведінку між двома операційними системами щодо відкриття та читання /etc/resolv.conf?

debian redhat domain-name-system

— користувач1311618
джерело

Чи можете ви, будь ласка, вставити повні сліди.

— Даніла Ладнер

Відповіді:

Розробники RedHat glibc вважають, що деякі помилки у своєму програмному забезпеченні не є помилками. Однією з таких помилок є повторне читання resv.conf після зміни. glibc вважає, що відповідальність за додаток, тому для кожної програми потрібно створити для цього свою логіку.

Оскільки це абсолютно бонкери, розробники eglibc виправили цю проблему. Тож у системах, які не є eglibc, вашій програмі потрібно буде мати власну логіку для повторної ініціалізації nss_dns, інакше її потрібно буде перезапустити після зміни резолюції.conf. У системах eglibc (Debian і речі, засновані на Debian) ви отримуєте менш баггічну libc.

Ми з'ясували це важким способом після зміни резолюції.conf, виведення з експлуатації старих серверів DNS, а потім необхідності перезавантаження 1200+ серверів mysql. Потрібно говорити, що це не весело.

— Денніс Каарсемейкер
джерело

Чому це вважається "абсолютно бонкерами"? І чому glibc зробив це так?

— Майкл Хемптон

Тому що замість того, щоб фіксувати glibc, вони покладають тягар на кожну програму там ... Що стосується того, чому вони це роблять? Не знаю. Я не можу прочитати розуму Dreppers, і я не впевнений, що хочу знати, що там відбувається ...

— Dennis Kaarsemaker

Річ у тім: я не впевнений, що glibc насправді зламаний. Чому потрібно /etc/resolv.confперечитувати при кожному пошуку DNS? Чи дійсно очікується, що це часто змінюватиметься? Тепер, якщо поведінка була недокументована, то я міг би зрозуміти ...

— Майкл Хемптон

Це не перечитується при кожному пошуку, що було б порушено також :) Поведінка є недокументованою та справді контрінтуїтивною: glibc несе відповідальність за ініціалізацію бібліотеки nss_dns, але згодом робить програму відповідальною за її повторну реалізацію, навіть якщо ці програми не знаю що-небудь про nss та як це працює. Як це не бонкери?

— Денніс Каарсемейкер

Денніс правий, гай у EL6 навмисно порушений, тому що поведінка баггі стала "очікуваною поведінкою" - access.redhat.com/site/solutions/541163

— suprjami

Не тільки версії бібліотеки С відрізняються, але CentOS використовує бібліотеку GNU C ( glibc), тоді як Debian використовує Embedded GLIBC ( eglibc), тому реальна реалізація системних викликів пошуку імен зовсім інша.

Можливо, це пояснює різну поведінку системних викликів між цими двома дистрибутивами.

Я припускаю, що InetAddress.getByNameперекладається на getaddrinfo(). Ви можете почати з читання джерела кожного syscall у відповідній реалізації бібліотеки C та версіях.

Переконайтеся, що ви прочитали джерело з фактичних версій пакету, які ви використовуєте. У пакетах EL 6.4 за 2 роки було вдосконалено порівняно з їх початковими версіями. Я припускаю, що це стосується пакетів Debian.

— suprjami
джерело