Perbedaan resolusi nama antara CentOS dan Debian

Saya memiliki program Java kecil yang loop memanggil InetAddress.getByName ("example.com") setiap detik. Ketika saya menjalankannya pada kotak CentOS 6.4 menggunakan 'strace -f' saya melihat bahwa /etc/resolv.conf dibuka dan dibaca sekali:

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

Ketika saya menjalankannya di Debian 7 saya melihat bahwa /etc/resolv.conf berulang kali dibuka atau 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

Kedua sistem memiliki konfigurasi /etc/nsswitch.conf

host: file dns

Sistem tidak memiliki daemon caching nama yang berjalan.

Saya menggunakan versi yang sama dari Oracle HotSot Java JVM pada kedua mesin untuk menyingkirkan perbedaan Java.

Kotak CentOS 6.4 telah menginstal glibc 2.12. Kotak Debian 7 telah menginstal glibc 2.13.

Apa yang menyebabkan perilaku yang berbeda antara kedua sistem operasi sehubungan dengan membuka dan membaca /etc/resolv.conf?

debian redhat domain-name-system

— pengguna1311618
sumber

Bisakah kau tolong lacak jejak penuh.

— Danila Ladner

Jawaban:

Pengembang RedHat glibc menganggap beberapa bug dalam perangkat lunak mereka bukan bug. Salah satu bug ini adalah membaca ulang resolv.conf setelah diubah. glibc menganggap bahwa tanggung jawab aplikasi, sehingga setiap aplikasi perlu membuat logikanya sendiri untuk ini.

Karena ini benar-benar gila, pengembang eglibc telah memperbaiki masalah ini. Jadi pada sistem non-eglibc, aplikasi Anda harus memiliki logikanya sendiri untuk menginisialisasi ulang nss_dns, jika tidak, aplikasi tersebut harus di-restart setelah perubahan resolv.conf. Pada sistem eglibc (Debian dan hal-hal berdasarkan Debian), Anda mendapatkan libc yang kurang buggy.

Kami menemukan ini dengan cara yang sulit setelah mengubah resolv.conf, menonaktifkan server DNS lama dan kemudian harus me-restart 1200+ server mysql. Tidak perlu dikatakan, ini tidak menyenangkan.

— Dennis Kaarsemaker
sumber

Mengapa ini dianggap "benar-benar gila"? Dan mengapa glibc melakukannya dengan cara ini?

— Michael Hampton

Karena alih-alih memperbaiki glibc, mereka menempatkan beban pada setiap aplikasi di luar sana ... Adapun mengapa mereka melakukannya? Saya tidak tahu Saya tidak bisa membaca pikiran Dreppers, dan saya tidak yakin ingin tahu apa yang terjadi di sana ...

— Dennis Kaarsemaker

Masalahnya adalah: Saya tidak yakin glibc benar-benar rusak. Mengapa harus /etc/resolv.confdibaca ulang di setiap pencarian DNS? Apakah ini benar-benar diharapkan untuk berubah sesering itu? Sekarang jika perilaku itu tidak berdokumen maka saya bisa mengerti ...

— Michael Hampton

Ini tidak membaca ulang di setiap pencarian, yang akan rusak juga :) Perilaku ini tidak berdokumen dan benar-benar berlawanan dengan intuisi: glibc mengambil tanggung jawab untuk menginisialisasi pustaka nss_dns, tetapi kemudian membuat aplikasi bertanggung jawab untuk menginisialisasi ulang, meskipun aplikasi tersebut tidak tahu apa saja tentang NSS dan bagaimana cara kerjanya. Bagaimana itu bukan gila?

— Dennis Kaarsemaker

Dennis benar, gai di EL6 sengaja dipatahkan karena perilaku buggy telah menjadi "perilaku yang diharapkan" - access.redhat.com/site/solutions/541163

— suprjami

Tidak hanya versi pustaka C yang berbeda, tetapi CentOS menggunakan pustaka GNU C ( glibc) sedangkan Debian menggunakan Embedded GLIBC ( eglibc), sehingga implementasi sebenarnya dari panggilan pemanggilan nama sistem sama sekali berbeda.

Itu mungkin akan menjelaskan perilaku sistem panggilan yang berbeda antara kedua distribusi ini.

Saya menganggap InetAddress.getByNamediterjemahkan ke dalam getaddrinfo(). Anda bisa mulai dengan membaca sumber setiap syscall di implementasi dan versi C library yang relevan.

Pastikan Anda membaca sumber dari versi paket aktual yang Anda gunakan. Paket-paket dalam EL 6.4 telah mengalami perbaikan lebih dari 2 tahun dibandingkan dengan versi hulu aslinya. Saya berasumsi hal yang sama berlaku untuk paket Debian.

— suprjami
sumber