Fechando um socket que fica esperando um processo filho, quando o processo pai foi morto

Question

A situação é a seguinte:

• Um processo de serviço / pai é conectado a uma "porta pública" (o processo pai é um serviço). Essa "porta pública" é 11000. Quando novas solicitações chegam ao processo pai da porta 11000, o servidor envia essas solicitações para um processo filho usando uma porta "privada" (soquete). Você sabe, a maneira típica de implementar servidores.

• O processo pai é eliminado, mas o soquete não está fechado (ainda não sei o motivo).

• O processo órfão está aguardando o fechamento do soquete e o pkill não funciona (está em modo ininterrupto de suspensão).

• Não consigo executar o servidor novamente porque o servidor informa que o endereço (0.0.0.0:11000) já está em uso.

Então, eu tenho duas opções, para fechar o "socket interno" para concluir o processo órfão, ou "free" de alguma forma o endereço / porta 0.0.0.0:11000 para executar o servidor novamente, e deixar o processo órfão em espera Estado. A coisa é evitar reiniciar o servidor toda vez que ele falhar, enquanto eu investigar o problema.

Informações úteis sobre a situação (o pid do processo infantil é 1993):

$ sudo lsof -np 1993

[...]
proc 1993 root 16u  IPv4  14997  0t0  TCP 127.0.0.1:42982->127.0.0.1:37528 (CLOSE_WAIT)

Portanto, a porta que eu quero fechar é 37528. O descritor de arquivo do soquete correspondente é 16u (ou é o que eu acho).

$ sudo strace -p 1993

Process 1993 attached
futex(0x2fff414, FUTEX_WAIT_PRIVATE, 1, NULL

$ netstat -np
[...]
tcp      0   0 127.0.0.1:42982     127.0.0.1:37528    CLOSE_WAIT  -  

Se eu tentar conectar-me ao processo órfão por meio de gdb :

$ gdb -p 1993
Attaching to process 1993
{process_path} (deleted): No such file or directory.

Porque o processo pai é morto, eu acho. O problema é que não consigo me conectar ao processo órfão para chamar close(16u) .

Como posso "resolver" a situação?

NOTES : Eu já tentei reiniciar o serviço networking , mas não funciona. É um servidor Ubuntu 14.04 (VirtualBox), e eu conecto a minha máquina usando o ssh. Não há gerenciador de rede.

Eu tentei aplicar ifdown , ifup a cada interface (eth0, eth1, e y virbr), mas eles não fecharam o soquete.

    

Answer 1

Não há um caminho fácil. Primeiro, isso não tem nada a ver com rede : CLOSE_WAIT é o status que seu processo filho digita depois de responder a um pacote FIN com um > ACK e antes de fechar o socket e enviar ao seu par um pacote FIN . Durante o estado CLOSE_WAIT , o processo está concluindo alguma operação no final da qual ele irá chamar close () , o que solicita ao kernel que envie o pacote FIN.

Em outras palavras, durante o estado CLOSE_WAIT o processo está tentando concluir alguma operação, não esperando por algo de um par; portanto, desligar a rede, reiniciar as interfaces e assim por diante não conseguirá nada.

Em geral, isso não deve ser per se um grande problema: não há nada de errado em ter alguns processos pendurados em um estado CLOSE_WAIT . O que o incomoda sobre isso é difícil de entender: você afirma que o processo pai atende na porta 11000 e, em seguida, contata o filho na porta 37528, mas você afirma que, depois que o processo pai morreu, não é possível iniciar uma nova instância do servidor. a porta 11000 não é liberada. Mas você acabou de afirmar que não é o processo infantil que está usando isso! Então quem é?

De qualquer forma, há apenas algumas coisas que você pode tentar:

1. você tentou matar um processo com a opção -9 ? É o mais strong que você pode inventar.

2. Você pode usar strace desde o início para rastrear as chamadas do sistema, mesmo nos processos filhos (ou é processos filho?), por meio de

   strace -f YourParentProcess
   

   Isso também seguirá os processos * fork () * ed.

3. Meu palpite é que você pode muito bem esquecer a criança e tentar determinar por que a porta 11000 parece ocupada e por quem. Você deve tentar o comando mais prático

   ss -lntp | grep 11000
   

   para investigar o assunto.