Porta di rete aperta, ma nessun processo collegato?

Ho una strana situazione in corso con una porta di rete aperta. La mia domanda principale è: perché non dovrebbe esserci un programma associato a una porta TCP aperta:

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      -  

Per il mio caso specifico, dovrebbe esserci un demone nrpe (opsview install) in ascolto sulla porta 5666, ma non è in esecuzione alcun demone nrpe. Se provo ad avviarlo, si esce immediatamente.

lsof -i :5666non mostra alcun output neanche. Non c'è (x) inetd in esecuzione sul mio sistema.

AGGIORNARE

Sì, stavo eseguendo quei comandi come root. Telnet avrebbe potuto, ma non c'è mai stata alcuna risposta.

Dopo ulteriori indagini, ho riscontrato un errore del kernel in dmesg: si trattava di un'istanza EC2 (in realtà molte di esse) che eseguiva un kernel più vecchio (2.6.16 è apparentemente instabile). La soluzione per arrestare l'incidente era aggiornare i kernel .

Sembra che il modo in cui il kernel si è arrestato in modo anomalo abbia causato la scomparsa del processo e l'apertura della porta.

Le porte aperte dal kernel non verranno visualizzate con il nome del programma. Vengono in mente alcune cose di NFS e OCFS. Forse è qualcosa del genere?

O potrebbe essere un bug del kernel. Controlla i log del kernel per OOPS e BUG.

Hai eseguito netstat e lsof come root o con sudo? Nota l'ultima colonna:

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

Dalla manpage netstat:

Avrai anche bisogno dei privilegi di superutente per vedere queste informazioni su socket che non possiedi.

Come fai a sapere che non ce n'è uno in esecuzione? Se la porta è in uso ha senso che uscirà immediatamente con un errore "socket in uso". cosa succede quando telnet alla porta?

telnet localhost 5666

eseguire 'netstat --tcp --udp --listening --program' come utente root . altro che saggio non ti darà PID / nome del programma

quindi usa il comando kill -9 PID

In realtà ho scritto un piccolo script di shell per aiutare a identificare queste domande occasionali:

#! /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

salva come / usr / local / bin / tracer; produzione:

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

Avrai bisogno dei privilegi di root per usarlo

Sono stato in grado di rintracciare il processo ottenendo il suo inode tramite netstat e quindi usando quell'inode con lsof. Vedi la mia risposta più dettagliata in /server//a/847910/94376 .

A volte, i programmi relativi a nfs non possono essere visualizzati nell'elenco dei programmi.

Inoltre, i moduli pam LDAP e libnss_ldap aprono le connessioni ai server ldap, ma non esiste un processo effettivo che mantiene aperta la connessione, quindi netstat -tnp mostra una connessione attiva senza un processo.