O processo chamando getaddrinfo () na inicialização fica permanentemente preso com o /etc/resolv.conf incorreto?

Question

Estou executando pianod , um cliente / servidor Pandora, em um Raspberry Pi com Arch Linux ARM. Eu tenho pianod configurado para ser executado como um serviço na inicialização. Ele inicia antes da pilha de rede, portanto, getaddrinfo() falha. Isso deve estar bem; pianod está configurado para repetir o login da rede a cada 60 segundos.

(Além disso: tentei coisas óbvias para que systemd esperasse pela pilha da rede antes de iniciar o pianod , mas não estava funcionando. Na lista systemd , fui informado de que realmente deveria tentar para fazer meu processo se comportar bem se a rede não estiver disponível, uma perspectiva que eu possa apreciar.Há outros hacks para fazer meu processo dormir durante a inicialização, etc. Eu estaria interessado se houvesse um hack que fosse realmente padrão para alguns razão, mas preferiria uma solução limpa.)

Apesar de pianod tentar novamente a rede a cada 60 segundos após a falha inicial na inicialização, getaddrinfo() persiste ao retornar EAI_NONAME . Se eu reiniciar o processo manualmente, tudo funciona.

O problema parece ser que, na primeira chamada para getaddrinfo() na inicialização, res_init() é chamado e tenta carregar /etc/resolv.conf . Como o DHCP ainda não inicializou esse arquivo com informações de DNS adequadas (?), Isso carrega informações de DNS (localhost eu acho) incorretas na variável global _res do processo. O processo é então preso com EAI_NONAME .

Adicionar uma nova chamada manual a res_init() para recarregar as informações de DNS após falha das chamadas getaddrinfo() faz a coisa funcionar, ou seja, getaddrinfo() é bem-sucedido na primeira tentativa de login 60 s após a inicialização.

MAS ... Estou muito surpreso que isso seja um problema. Eu tenho outro serviço que faz essencialmente a mesma coisa e não parece precisar do manual res_init() . O outro processo faz um pouco mais fork() , mas não vejo onde ele escaparia do _res global ruim. Em geral, estou surpreso que o Linux esteja configurado para ter esse problema.

Então eu senti que deveria perguntar o que poderia estar perdendo aqui. Minha interpretação parece correta? Em caso afirmativo, por que isso não é tratado melhor a montante? Se não, o que mais eu deveria olhar? Existem maneiras padrão melhores de lidar com isso?

UPDATE: conforme solicitado, aqui está a descrição da unidade de serviço atual. Eu tentei adicionar After=network.target , bem como Requires . Pelo que os systemd disseram, eles não são confiáveis de uma distro para a próxima ...

[Unit]
Description=Pandora Client Daemon
After=syslog.target

[Service]
EnvironmentFile=/etc/pianod.env
ExecStart=/usr/sbin/pianod $INITSCRIPT $USERFILE $PORT $LOGGING -nroot
Restart=on-abort

[Install]
WantedBy=multi-user.target

    

Answer 1

As interfaces Unix e o design interno datam de uma época em que uma configuração de rede era uma coisa muito estática. Não havia laptops e nenhum endereço IP dinâmico atribuído pelo DHCP. Portanto, o sistema não foi projetado para enviar um evento aos aplicativos quando a configuração de rede é alterada. As aplicações lêem a configuração do DNS em /etc/resolv.conf uma vez quando começam, e é isso.

A maneira moderna de lidar com as alterações nas configurações de rede é executar um proxy DNS local. É certo que demorou muito tempo, mas cada vez mais distribuições estão começando a fazer disso uma configuração padrão (acho que o Ubuntu começou a fazer isso com 12.04). Tenha apenas 127.0.0.1 listado como um servidor de nomes em /etc/resolv.conf e deixe seu proxy DNS lidar com as mudanças na configuração.

Dnsmasq é uma escolha popular para servidores e proxy DNS leves. Escolha a menos que você tenha um bom motivo para escolher outro. É o que o Ubuntu usa. É também o que meu roteador doméstico com um processador MIPS e 16MB RAM é executado, então o seu Pi é strongmente sobrecarregado para executá-lo.

Como de costume, o Arch Linux não vem com uma configuração de trabalho pronta para uso, mas o wiki tem claro e instruções detalhadas.