Estou no Ubuntu 16.04 e executando um programa nodejs que está pesquisando uma API REST. Ele estava trabalhando por cerca de 3 horas pesquisando o mesmo site a cada poucos segundos e depois falhou dizendo que não poderia encontrar o site. Estou recebendo um erro do nó: "failed, reason: getaddrinfo ENOTFOUND".
Este é um programa de nó que eu comecei a executar via nohup & e tinha então desconectado. Ele estava funcionando, o que eu poderia verificar através do meu site e porque o processo estava criando um arquivo de log de saída durante a operação.
Isso pareceu muito estranho porque estava indo para o mesmo endereço por horas. Eu verifiquei os logs. Em auth.log ao mesmo tempo em que o log de saída parou, vi a seguinte entrada:
May 24 01:38:29 order-gateway systemd-logind[1028]: Removed session 237.
Neste momento (01:38) não havia usuário logado. A sessão 237 foi iniciada:
May 23 17:22:38 order-gateway systemd-logind[1028]: New session 237 of user ubuntu.
Acredito que a sessão em que iniciei o processo foi 238 (embora não tenha certeza). Não faz qualquer sentido para mim que 1) uma sessão seja removida horas após o usuário efetuar o logout e 2) que a remoção de uma sessão cause um soluço no DNS.
Informações adicionais: o resolv.conf é definido automaticamente e usa o DNS do Google (8.8.8.8). Aqui está o que eu tenho:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 8.8.8.8
nameserver 8.8.4.4
search openstacklocal
Eu não configurei. Por favor ajude. Eu adoraria aprender o que está acontecendo e, claro, consertar o problema.
Atualização: Eu tenho monitorado a situação e confirmei que quando a sessão que iniciei o processo é removida (systemd-logind [1001]), o processo registra um erro e termina. Isto é depois de ter editado o logind.conf para descomentar KillUserProcesses = no para que os processos do usuário não sejam mortos.
Atualização do Addl: A direção causal não está se tornando tão clara. Eu estou suspeitando que o endpoint é potencialmente instável e que o processo de kill ocorre logo após o programa falhar. Eu gostaria de entender por que o DNS se torna instável. Suporte sugerido manualmente adicionando o ponto de extremidade para / etc / hosts que parece ter funcionado (outra questão posteriormente matou o programa, mas ele correu muito mais do que eu esperava, e é por isso que estou pensando em inverter a causalidade).