Diferença na resolução de nomes entre o CentOS e o Debian

13

Eu tenho um pequeno programa Java que executa o loop de InetAddress.getByName ("example.com") a cada segundo. Quando o executo em uma caixa do CentOS 6.4 usando 'strace -f', vejo que /etc/resolv.conf é aberto e lido uma vez:

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

Quando o executo no Debian 7, vejo que /etc/resolv.conf é aberto repetidamente ou 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

Ambos os sistemas têm o /etc/nsswitch.conf configurado com

hosts: arquivos dns

Nenhum sistema possui um daemon de armazenamento em cache de nomes em execução.

Usei a mesma versão da Oracle HotSot Java JVM em ambas as máquinas para descartar quaisquer diferenças de Java.

A caixa do CentOS 6.4 possui o glibc 2.12 instalado. A caixa Debian 7 tem o glibc 2.13 instalado.

O que explica o comportamento diferente entre os dois sistemas operacionais em relação à abertura e leitura do /etc/resolv.conf?

debian redhat domain-name-system user1311618
fonte
Você pode colar os rastros completos.
Danila Ladner

Respostas:

10

Os desenvolvedores glibc do RedHat consideram que alguns bugs em seus softwares não são bugs. Um desses erros é a releitura do resolv.conf após a alteração. A glibc considera que é de responsabilidade do aplicativo, portanto, todo aplicativo precisará criar sua própria lógica para isso.

Como isso é absolutamente doido, os desenvolvedores do eglibc corrigiram esse problema. Portanto, em sistemas não eglibc, seu aplicativo precisará ter sua própria lógica para reinicializar o nss_dns, caso contrário, precisará ser reiniciado após uma alteração no resolv.conf. Nos sistemas eglibc (Debian e coisas baseadas no Debian), você obtém uma libc com menos bugs.

Descobrimos isso da maneira mais difícil depois de alterar o resolv.conf, encerrar os servidores DNS antigos e depois ter que reiniciar mais de 1200 servidores mysql. Escusado será dizer que isso não é divertido.

Dennis Kaarsemaker
fonte
Por que isso é considerado "absolutamente maluco"? E por que a glibc fez dessa maneira?
Michael Hampton
1
Porque, em vez de consertar o glibc, eles sobrecarregam todos os aplicativos existentes ... Por que o fazem? Eu não sei. Eu não consigo ler a mente de Dreppers, e não tenho certeza se quero saber o que está acontecendo lá ...
Dennis Kaarsemaker
1
A questão é: não tenho certeza se o glibc está realmente quebrado. Por que deve /etc/resolv.confser relido a cada pesquisa de DNS? É realmente esperado que mude com frequência? Agora, se o comportamento não tiver sido documentado, então eu pude entender ...
Michael Hampton
1
Não é relido em todas as pesquisas, isso também seria quebrado :) O comportamento não é documentado e é realmente contra-intuitivo: o glibc assume a responsabilidade de inicializar a biblioteca nss_dns, mas posteriormente torna o aplicativo responsável por reinicializá-lo, mesmo que esses aplicativos não o sejam. sabe algo sobre o nss e como ele funciona. Como isso não é maluco?
Dennis Kaarsemaker
1
Dennis está certo, gai em EL6 é intencionalmente quebrado porque o comportamento de buggy tornou-se o "comportamento esperado" - access.redhat.com/site/solutions/541163
suprjami
4

Não são apenas as versões da biblioteca C diferentes, mas o CentOS usa a biblioteca GNU C ( glibc) enquanto o Debian usa o Embedded GLIBC ( eglibc), portanto a implementação real das chamadas do sistema de busca de nomes é completamente diferente.

Provavelmente, isso representaria um comportamento diferente de chamada do sistema entre essas duas distribuições.

Eu assumo InetAddress.getByNametraduz em getaddrinfo(). Você pode começar lendo a fonte de cada syscall na implementação e nas versões relevantes da biblioteca C

Certifique-se de ler a fonte das versões reais do pacote que você está usando. Os pacotes no EL 6.4 tiveram mais de 2 anos de melhorias feitas em comparação com as versões originais do upstream. Presumo que o mesmo se aplica aos pacotes Debian.

suprjami
fonte