xinetd mantém o processo aberto quando o cliente desconecta

0

Eu fiz essa pergunta mais ou menos antes no stackoverflow e acreditei que ela fosse resolvida (daí a resposta aceita), mas acabou não sendo resolvido. : - (

Em termos simples, eu escrevi um script python que apenas envia texto constantemente para stdout, isso é tudo que ele faz 24/7. Eu o vinculei a este arquivo xinetd

service myservice
{
    instances = 1
    port = 887
    socket_type = stream
    type = UNLISTED
    wait = no
    user = nobody
    server = /usr/local/bin/myscript.py
    only_from = 127.0.0.1 192.168.1.2
    disable = no
    max_load = 5.0
    nice = 5
    per_source = 1
}

Isso funciona bem, na medida em que, quando um cliente se conecta, ele começa a emitir texto em seu console. O problema é quando o cliente desconecta, o processo lançado fica aberto, bloqueando a porta. Há apenas um cliente permitido (instâncias = 1), mas isso pode ocorrer quando o cliente é reinicializado enquanto conectado.

Anteriormente, eu achava que isso era porque o script python estava ignorando sinais de kill (o que era), mas com isso fixo, o mesmo comportamento é observado. Para esclarecer, matar -1 etc agora é felizmente observado pelo script python.

Estou assumindo que este é um problema do xinetd e bastante simples de corrigir?

    
por Sirex 17.09.2010 / 10:46

2 respostas

1

Faça o processo do servidor sair quando detectar uma desconexão.

Added Quando o SO do servidor detecta que a conexão TCP foi fechada, as leituras e gravações de stdout / stderr falharão com:

IOError: [Errno 104] Connection reset by peer

Certifique-se de que seu código não esteja ignorando exceções quando elas ocorrerem.

No entanto, este (e qualquer outro método) só funciona quando o servidor sabe sobre a desconexão. As reinicializações limpas geralmente fecham todas as conexões TCP, mas "puxar o plugue" não.

    
por 17.09.2010 / 15:44
-1

Você tentou definir wait = yes ?

De acordo com a documentação, isso é

wait — Defines whether the service is single-threaded (yes) or multi-threaded (no).
    
por 17.09.2010 / 11:12