Porta de rede aberta, mas sem processo anexado?

Question

Eu tenho uma situação estranha acontecendo com uma porta de rede aberta. Minha principal questão é, 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      -  

Para meu caso específico, supõe-se que haja um daemon nrpe (opsview install) atendendo na porta 5666, mas não há nenhum daemon nrpe em execução. Se eu tentar iniciá-lo, ele sai imediatamente.

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

UPDATE

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

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

Parece que a maneira como o kernel travou fez com que o processo desaparecesse e deixasse a porta aberta.

    

Answer 1

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

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

    

Answer 2

Você executou o netstat e o lsof como root ou com o 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 do man netstat:

You will also need superuser privileges to see this information on sockets you don’t own.

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

telnet localhost 5666

    

Answer 3

execute 'netstat --tcp --udp --listening --program' como usuário root . caso contrário você não dará PID / Program Name

use kill -9 comando PID

    

Answer 4

Na verdade, escrevi um pequeno script de shell para ajudar a identificar essas questões 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

    

Answer 5

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

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

    

Answer 6

Consegui rastrear o processo obtendo seu inode via netstat e usando esse inode com lsof. Veja minha resposta mais detalhada no link .