php-fpm php_network_getaddresses chamadas aleatoriamente começam a falhar com mau udp cksum

Question

Estamos executando vários servidores da web (nginx, php5.6-fpm) em instâncias do ubuntu na AWS. Eles funcionam bem há vários meses, mas nos últimos dias começamos a receber problemas nos quais, depois que uma instância é gerada, tudo fica bem, mas depois de 12 horas, as chamadas de rede começam a falhar (especificamente neste caso). instancia o socket tcp chama para redis).

Tendo feito algumas pesquisas com o tcpdump, parece que as pesquisas de dns estão sendo descartadas devido a uma falha na soma de verificação do udp:

17: 13: 38.013346 IP (tos 0x0, ttl 64, id 46236, offset 0, sinalizadores [DF], proto UDP (17), comprimento 103)     10.0.0.121.34071 > 10.0.0.2.53: [mau udp cksum 0x14df - > 0x3ae1!] 25855+ Type20736? xxxxxxxx.us-east-1.rds.amazonaws.com. (75)

Se eu usar o telnet para se conectar ao servidor Redis a partir da mesma instância, tudo bem, ele só parece afetar o fpm. Igualmente estranho, só acontece um pouco depois que a instância foi iniciada - inicialmente todas as solicitações passam bem. Da mesma forma, reiniciar o serviço php5.6-fpm parece resolver o problema por um tempo.

Estou bem no final do meu conhecimento neste momento, então espero que alguém possa me apontar na direção certa!

    

Answer 1

Você tem uma correção de segurança defeituosa instalada - isso soa como o problema de USN-3239-2 .

Uma atualização de segurança para o GNU libc que foi endereçada (entre outras coisas) ...

an unbounded stack allocation in the getaddrinfo() function of the GNU C Library.

.... continha uma regressão - uma alteração não intencional da ABI - que parece ter causado problemas semelhantes aos descritos por você ... A resolução de DNS acabaria parando de funcionar até que os processos fossem reiniciados.

A atualização original foi lançada em 20/03/2017 e a correção foi lançada em 21/03/2017. Aplicar as correções de segurança mais recentes do sistema operacional deve resolver o problema, se for isso.

    

Answer 2

As más somas de verificação podem ser devidas ao descarregamento da soma de verificação .

Gostaria de verificar se é esse o caso, o que você pode fazer executando:

sudo ethtool --show-offload ethX

Pode valer a pena cavar um pouco mais sobre o que o tcpdump pode dizer sobre o conteúdo de seus pacotes, no entanto - eu gostaria de saber se você pode não estar atingindo algum tipo de limitação de taxa. Você pode querer verificar os pacotes de retorno para NXDOMAIN ou similar.

Se esse era o problema, ter algum tipo de resolvedor de cache poderia ajudar.

atualizado para responder aos comentários abaixo:

Se reiniciar o serviço em si é 'corrigir' o problema (obrigado @ Liam Wiltshire para obter as informações adicionadas) , então eu concordo que a limitação de taxa não parece correta (ou pelo menos, a limitação de taxa pelo upstream não é).

Suponho que o limite de taxa devido a recursos locais ainda possa ser uma possibilidade a ser considerada: por exemplo, garantir que não haja um limite de entradas de conntrack ou ulimit 'arquivos abertos (por exemplo, nofiles é baixo.

Dito isto, o patch de segurança ruim / lead de software ruim parece bastante mais promissor - então eu definitivamente daria peso (e daria pontos) para @ Michael - sugestões do sqlbot .