Porta de rede aberta, mas nenhum processo foi anexado?

Eu tenho uma situação estranha acontecendo com uma porta de rede aberta. Minha principal pergunta é: por que não haveria um programa associado a uma porta TCP aberta:

netstat -ln --program
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
tcp        0      0 0.0.0.0:5666                0.0.0.0:*                   LISTEN      -  

No meu caso específico, deveria haver um daemon nrpe (instalação do opsview) escutando na porta 5666, mas não há daemon nrpe em execução. Se eu tentar iniciá-lo, ele sai imediatamente.

lsof -i :5666também não mostra nenhuma saída. Não há (x) inetd em execução no meu sistema.

ATUALIZAR

Sim, eu estava executando esses comandos como root. Telnet poderia, mas nunca houve resposta.

Após uma investigação mais aprofundada, encontrei um erro no kernel dmesg: esta era uma instância do EC2 (na verdade várias delas) executando um kernel mais antigo (2.6.16 é aparentemente instável). A correção para interromper o travamento foi atualizar os kernels .

Parece que a maneira como o kernel travou fez com que o processo fosse interrompido e deixou a porta aberta.

Portas abertas pelo kernel não aparecerão com o nome do programa. Algumas coisas sobre NFS e OCFS vêm à mente. Talvez seja algo assim?

Ou pode ser um bug do kernel. Verifique os logs do kernel quanto a OOPS e BUG.

Você executou netstat e lsof como root ou com sudo? Observe a última coluna:

netstat -ln --program
tcp        0      0 192.168.21.1:53         0.0.0.0:*               LISTEN      -               
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      -               
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -

sudo netstat -ln --program
tcp        0      0 192.168.21.1:53         0.0.0.0:*               LISTEN      2566/named      
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      2566/named      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      3125/sshd

Na página de manual netstat:

Você também precisará de privilégios de superusuário para ver essas informações nos soquetes que você não possui.

Como você sabe que não há um em execução? Se a porta estiver em uso, faz sentido que ela saia imediatamente com um erro 'soquete em uso'. o que acontece quando você faz telnet para a porta?

telnet localhost 5666

execute 'netstat --tcp --udp --listening --program' como usuário root . caso contrário, você não fornecerá o PID / nome do programa

então use o comando kill -9 PID

Na verdade, escrevi um pequeno script de shell para ajudar a identificar essas perguntas ocasionais:

#! /bin/bash
([ "$1" = "" ] || [ "$2" = "" ]) && echo "Usage: tracer <space> <port>" && exit 0
for i in `fuser -n $1 $2`
 do
  ps aux | grep $i | grep -v 'grep'
 done

salve como / usr / local / bin / tracer; saída:

root@mo-log:/usr/flows# tracer tcp 80
80/tcp:             
root     27904  0.0  0.0 111668  3292 ?        Ss   Aug04   0:03 /usr/sbin/apache2 -k start
www-data 32324  0.0  0.0 335332  3560 ?        Sl   Aug05   0:00 /usr/sbin/apache2 -k start
www-data 32327  0.0  0.0 335324  3560 ?        Sl   Aug05   0:00 /usr/sbin/apache2 -k start

Você precisará de privilégios de root para usá-lo

Eu era capaz de rastrear o processo, obtendo seu inode via netstat e depois usando esse inode com lsof. Veja minha resposta mais detalhada em /server//a/847910/94376 .

Às vezes, os programas relacionados ao nfs não podem ser vistos na lista de programas.

Além disso, os módulos LDAP pam e libnss_ldap abrem conexões com os servidores ldap, mas como não há um processo real mantendo a conexão aberta, o netstat -tnp mostra uma conexão ativa sem um processo.