Eu tenho um processo - um script perl - que:
while true
check a POP account on a server on the lan
process any email found
write logs - messages found, actions taken, errors
sleep for 15 seconds
Ele está rodando em um servidor redhat 7.3 (eu o herdei, não estou feliz com a idade da caixa). Está sem o / etc / inittab como:
spop:2345:respawn:/usr/local/gw/bin/popdmn
Se ele morrer, o init reinicia.
Nos últimos dois dias, o processo não funcionará mais a menos que seja alterado. Quando está apenas em execução, nunca se conecta ao servidor pop. Assim que é straced (via "strace -Ff -p cat /usr/local/gw/var/popdmn.pid "), ele funciona perfeitamente.
Como solução alternativa, estou executando a tela no servidor com uma cadeia em execução. Obviamente, isso é menos que ideal.
Por que um processo faria isso? Eu não vi isso acontecer antes.
Eu acho que fui mordido por um antigo bug de strace:
Esta caixa tem strace-4.4-4, então parece possível que seja esse bug. Parece que este é auto-infligido, pois estávamos nos esforçando ao mesmo tempo em que tentávamos depurar - e piorá-lo.
kill -CONT trabalha para retomar o processo.
Definitivamente tempo para atualizar esta caixa.
O maior ponto de diferença é o processamento de velocidade e sinal, suponho.
Em relação à velocidade, se o processo for multithreaded, o strace alterará o tempo, o meu comportamento de mudança em relação às condições de corrida, etc. ou informações de tempo relacionadas ao comportamento do protocolo.
Exemplo. Digamos que o servidor POP foi atualizado e agora é mais cuidadoso ao garantir que um par não tenha enviado vários comandos POP de cada vez. Isso é mais útil em um servidor SMTP como meio de prevenção de spam.
O seu processo observa o comportamento correto do POP, na medida em que aguarda uma resposta do servidor após cada um dos comandos POP? Ou assume sucesso ou espera algum tempo entre os comandos.
Se você capturar o tráfego real do protocolo em um caso de aprovação e reprovação, há algum sinal de violação de protocolo?