PHP: gethostbyname () repentinamente não resolve nomes para IPs quando executado no Apache

4

Um de nossos antigos servidores legados que não recebe mais atualizações ou reconfigurações de repente parou de resolver nomes de host para IPs quando o PHP é executado dentro do Apache. No entanto, ainda funciona bem quando executado a partir do CLI.

A partir da hora da última modificação dos caches RSS, deduzo que parou de funcionar por volta de 28 de março.

Para reproduzir o problema, criei um script usando fsockopen() e ele disse "connection failed (errno 2)". Reduzi ainda mais o problema de estar relacionado com uma resolução de nomes falhada:

<?php $addr = gethostbyname("twitter.com"); echo "ADDR($addr)"; ?>

Quando eu executo isso através do Apache, a saída é ADDR(twitter.com) , o que está errado.

Quando executo isso a partir da CLI, a saída é ADDR(aaa.bbb.ccc.ddd) com endereços IP variados, como esperado.

Nada na configuração do servidor foi alterado. O módulo CLI e Apache compartilha o mesmo php.ini . O PHP é a versão v4.4.9 com o Zend Optimizer v2.5.10. Apache é v1.3.31.

Eu sei que as versões são antigas. Mas como nada foi alterado, uma solução como "tente atualizar as versões primeiro" não é uma solução, pois o conjunto de recursos / versão do servidor está congelado e será substituído em breve. Ainda precisamos de uma solução.

Se eu executar dig através do script, ele funcionará nos dois ambientes (mod_php e CLI), mas isso é mais do que um hack feio, pois envolveria muitas edições e testes em toda a base de scripts, que também é indesejável. A aplicação PHP no servidor também está congelada e recebe apenas atualizações de segurança. Ele será substituído por uma reescrita completa (no novo servidor).

Mas, como a reescrita levará algum tempo e sucessivas partes de substituição do aplicativo legado, precisamos de uma correção para o problema do resolvedor. Eu já pesquisei um pouco e enquanto o problema é conhecido, muitos não encontraram uma correção. A correção para aumentar os limites de memória não funcionou. Reinícios não funcionaram. O resolvedor em mod_php simplesmente parou de funcionar sem razão aparente. : - (

Atualização: Eu resolvi isso enquanto parei o apache, esperando por um momento, e depois comecei novamente. Mas isso não explica a causa raiz desse comportamento (e, portanto, não há solução satisfatória). Então deixo isso em aberto.

    
por hurikhan77 06.04.2010 / 16:37

3 respostas

6

Nem uma reinicialização normal nem uma reinicialização normal funcionaram. Eu precisava parar completamente o apache, esperar que todos os processos terminassem e iniciar o apache novamente. Problema resolvido. Como ninguém parece encontrar uma explicação para a causa raiz desse comportamento, estou aceitando minha própria solução.

    
por 28.04.2010 / 11:19
1

O mesmo aqui O.K quando executado a partir do CLI, erro quando executado através do Apache. Eu acho que isso tem algo a ver com mudanças nos servidores de nome, por exemplo em /etc/resolv.conf. De alguma forma, o Apache (outros programas também são afetados) não verifica se há servidores de nomes alterados e não consegue resolver. Isso acontece comigo quando eu troco de rede com meu laptop. Eu tenho que parar manualmente o apache, ópera, firefox, etc para que eles obtenham as novas configurações do servidor de nomes.

    
por 21.07.2010 / 17:45
-1

Dos comentários no manual do PHP.net em gethostbyname :

If name resolution fails with apache2, mod_chroot and php5, add LoadFile /lib/libnss_dns.so.2 to the mod_chroot config.

e

When using PHP and Apache in a chroot environment on RedHat Linux, I have found that I need to bind-mount /var/run/nscd to get this to work. Apparently, the socket in that directory is needed for all the DNS things.

    
por 06.04.2010 / 20:24