Estou executando o Netcat em um servidor Ubuntu 18.04.3 LTS, para escutar na porta 469. Este servidor recebe solicitações TCP frequentes de outras máquinas para a porta 469, que eu uso para monitorar o tempo de atividade do servidor. Eu inicio o Netcat com:
nc -kl 469
e posso ver que o processo está ativo com:
$ ps -aux | grep 469que produz esta saída:
raiz 11041 0,0 0,1 13596 1060 ? S 31 de agosto 0:21 nc -kl 469`
Este sistema funciona bem por cerca de 24 a 28 horas, mas então o Netcat para de responder. Depois de investigar, acredito que o problema é que o buffer do Recv-Q "enche". Normalmente, o buffer Recv-Q é zero até o ponto em que o Netcat para de responder. Depois de parar de responder, o buffer Recv-Q é uma constante 2 (em vez do 0 normal). Posso verificar isso com "ss" da seguinte maneira.
$ ss -tnle então vejo isto, onde o Recv-Q anormal de 2 é visível.
$ ss -tnl
State Recv-Q Send-Q Endereço local:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 64 0.0.0.0:42587 0.0.0.0:*
LISTEN 0 128 0.0. 0.0:46663 0.0.0.0:*
ESCUTE 0 128 0.0.0.0:111 0.0.0.0:*
ESCUTE 2 1 0.0.0.0:469 0.0.0.0:*
ESCUTAR 0 128 127.0.0.53%lo:53 0.0.0.0:*
ESCUTAR 0 128 [::]:22 [::]:*
ESCUTAR 0 64 [::]:44057 [::]:*
ESCUTAR 0 128 [ ::]:55085 [::]:*
ESCUTE 0 128 [::]:111 [::]:*
Temos vários outros servidores Ubuntu, que também rodam o Netcat escutando na porta 469, exatamente da mesma maneira. Eles NÃO falham - eles estão ativos há semanas. Mas este servidor falha repetidamente, mesmo após a reinicialização, e sempre após cerca de 24 horas ou mais. A única diferença entre este e os outros servidores (que eu possa imaginar) é que este servidor também possui um volume nfs montado (como pode ser visto na escuta da porta 111 acima).
O que poderia ser que causa isso? Posso limpar o Recv-Q de alguma forma (do bash), para poder limpá-lo com algum intervalo regular (como uma correção temporária)? Qualquer ajuda é muito apreciada.
Responder1
Agora encontrei a resposta para esta pergunta e gostaria de publicá-la aqui, caso possa ajudar mais alguém.
O problema era que o servidor também tinha o Strongswan instalado e as solicitações TCP recebidas para a porta 469 vinham de uma conexão IPSec de outro servidor. O que aconteceu foi que a conexão IPSEC às vezes era interrompida por um período muito curto quando a conexão IPSec era recodificada (aproximadamente a cada 24 horas). Se isso acontecesse no meio de um TCP Syn/Ack em andamento para a porta 469, isso o deixaria no limbo. E assim o "nc -kl" ficaria preso, com pacotes no buffer Recv-Q.
A solução foi configurar o Strongswan para que a recodificação acontecesse sem interrupção. O aprendizado foi que, em vez de procurar um problema com o buffer Recv-Q ou Netcat, era necessário entender a causa raiz - que neste caso era entender por que o TCP Syn/Ack não pôde ser concluído.