CentOS ve Debian arasındaki ad çözümleme farkı


13

Her saniye InetAddress.getByName ("example.com") çağıran döngüler küçük bir Java programı var. 'Strace -f' kullanarak bir CentOS 6.4 kutusunda çalıştırdığımda /etc/resolv.conf dosyasının açıldığını ve bir kez okunduğunu görüyorum:

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

Debian 7'de çalıştırdığımda, /etc/resolv.conf dosyasının tekrar tekrar açıldığını veya 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

Her iki sistem de /etc/nsswitch.conf ile yapılandırılmıştır.

hosts: dosyalar dns

Her iki sistemde de çalışan bir önbellek cini var.

Java farklılıklarını ekarte etmek için her iki makinede de Oracle HotSot Java JVM'nin aynı sürümünü kullandım.

CentOS 6.4 kutusunda glibc 2.12 yüklü. Debian 7 kutusunda glibc 2.13 yüklü.

/Etc/resolv.conf dosyasının açılması ve okunması açısından iki işletim sistemi arasındaki farklı davranışın nedeni nedir?


Lütfen tam izleri yapıştırır mısın?
Danila Ladner

Yanıtlar:


10

RedHat glibc geliştiricileri yazılımlarındaki bazı hataları hata olarak görmezler. Bu hatalardan biri, çözümlendikten sonra resolv.conf dosyasının yeniden okunmasıdır. glibc, uygulamanın sorumluluğunu dikkate alır, bu nedenle her uygulamanın bunun için kendi mantığını oluşturması gerekecektir.

Bu kesinlikle çılgınlık olduğu için eglibc geliştiricileri bu sorunu çözdüler. Yani eglibc olmayan sistemlerde, uygulamanızın nss_dns öğelerini yeniden başlatmak için kendi mantığına sahip olması gerekir, aksi takdirde bir resolv.conf değişikliğinden sonra yeniden başlatılması gerekir. Eglibc sistemlerinde (Debian ve Debian tabanlı şeyler), daha az hatalı bir libc elde edersiniz.

Resolv.conf dosyasını değiştirdikten, eski DNS sunucularını devre dışı bıraktıktan ve 1200+ mysql sunucusunu yeniden başlattıktan sonra bunu zor yoldan öğrendik. Söylemeye gerek yok, bu eğlenceli değil.


Bu neden "kesinlikle çılgın" olarak kabul edilir? Ve neden glibc bunu böyle yaptı?
Michael Hampton

1
Çünkü glibc'i düzeltmek yerine, yükü oradaki her uygulamaya yüklerler ... Neden yaptıkları için? Bilmiyorum. Dreppers'ın aklını okuyamıyorum ve orada neler olduğunu bilmek istediğimden emin değilim ...
Dennis Kaarsemaker

1
Mesele şu: glibc'nin gerçekten kırıldığından emin değilim. Neden /etc/resolv.confher DNS aramasında yeniden okunmalıdır? Gerçekten sık sık değişmesi bekleniyor mu? Şimdi davranış belgesiz olsaydı anlayabiliyordum ...
Michael Hampton

1
Her aramada tekrar okunmaz, bu da kırılacaktır :) Davranış belgelenmemiştir ve gerçekten mantıksızdır: glibc nss_dns kütüphanesini başlatma sorumluluğunu üstlenir, ancak daha sonra bu uygulamalar, nss ve nasıl çalıştığı hakkında her şeyi bilir. Bu nasıl çılgın değil?
Dennis Kaarsemaker

1
Dennis haklı, EL6'daki gai kasıtlı olarak bozuldu, çünkü buggy davranışı "beklenen davranış" haline geldi - access.redhat.com/site/solutions/541163
suprjami

4

Sadece C kütüphanesi sürümleri farklı olmakla kalmaz, aynı zamanda CentOS GNU C kütüphanesini ( glibc) kullanırken Debian Gömülü GLIBC ( eglibc) kullanır , bu nedenle isim arama sistemi çağrılarının gerçek uygulaması tamamen farklıdır.

Bu muhtemelen bu iki dağıtım arasındaki farklı sistem çağrısı davranışını açıklar.

Ben InetAddress.getByNameçevirir sanırım getaddrinfo(). İlgili C kütüphanesi uygulamasında ve sürümlerinde her bir sistem çağrısının kaynağını okuyarak başlayabilirsiniz.

Kaynağı kullandığınız gerçek paket sürümlerinden okuduğunuzdan emin olun. EL 6.4'teki paketler, orijinal yukarı akış versiyonlarına kıyasla 2 yıldan fazla iyileştirme yaptı. Aynı şeyin Debian paketleri için de geçerli olduğunu düşünüyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.