Como depurar um problema de fifo aberta rosca estranho?
-
21-08-2019 - |
Pergunta
Um serviço web está configurado para expor alguns de seus dados quando receber um sinal USR1. O sinal será enviado por um servidor xinetd quando recebe um pedido de um cliente remoto, por exemplo, nc myserver 50666. Quando o servidor web recebe o sinal USR1, ele abre uma dedicada fifo tubulação, escreve seus dados para o tubo, e depois fechar o tubo. Enquanto isso, o servidor xinetd lê o tubo e feeds para o cliente remoto.
Na maioria das vezes, eles funcionam muito bem, mas, ocasionalmente, por algum motivo, o cliente receberá registros duplicados. A partir do registro, parece que o tubo não se fechou corretamente e o cache é sobra, então quando o tempo ao lado que serve, tanto anterior e atual são enviados para o cliente. O problema é que não é constantemente acontecendo ao tentar reproduzir, infelizmente, não foi capaz de reproduzir uma vez.
A seguir estão os trechos simples para demonstrar o processo:
O servidor web: (webserver.py)
def SendStream(data, pipe):
try:
for i in data:
pipe.write(i + '\n')
pipe.flush()
finally:
pipe.close()
def Serve():
threading.Thread(target=SendStream, args=(data, pipe)).start()
O servidor xinetd.d: (spitter.py)
def Serve():
if not os.path.exists(PIPE_FILE):
os.mkfifo(PIPE_FILE)
os.kill(server_pid, signal.SIGUSR1)
for i in open(PIPE_FILE):
print i,
Então, o que exatamente aconteceu para causar a dup? Como provocá-lo? A correção atual para desvincular o arquivo de tubulação e recriá-lo cada vez para evitar quaisquer sobras, mas eu não sei se isso é uma solução adequada.
Solução
Se você receber duas cópias de splitter.py em execução ao mesmo tempo, haverá problemas e quase tudo o que acontece com você é legal. Tente adicionar um valor id processo para webserver.py, ou seja:
pipe.write (str (os.getpid ()) + i + '\ n')
Isso pode ser esclarecedor.
Outras dicas
Não é o suficiente para depurar aqui. Você não mostra como os sinais alças de servidor, ou abre o tubo.
Se possível Eu recomendaria não usando sinais. Eles são bastante peludo em C, deixa pra lá com peculiaridades de python adicionados no topo.
Assim, o verdadeiro problema é que existem vários clientes existem. O servidor foi consultado / abusado de outros clientes desconhecidos que não estavam inicialmente sendo acordados com os clientes e com certeza ele vai quebrar sob o projeto atual. Uma correção foi implementada para resolver a questão. Então, a suspeita de Andy está certo. Obrigado rapazes!