netstat -ntap non mostra il nome pid / process per alcune connessioni?

10

Ho un server ubuntu / hardy, con kernel 2.6.24-23-server e netstat:

# netstat --version
net-tools 1.60
netstat 1.42 (2001-04-15)

Il problema è che abbiamo molte connessioni STABILITE che non mostrano PID né nome del programma in netstat -ntapuscita. Netstat è stato chiamato da root, non ci sono chroot, grsecurity, né niente del genere (o almeno così mi è stato detto :).

Qualche idea su cosa potrebbe essere sbagliato?

AGGIORNARE

lsof -n -i funziona bene e mostra il nome pid / processo per le connessioni.

2

Sei sicuro di eseguirlo come root o con sudo?

— Dom

Sì, è stato eseguito su root e persino su root tramite sudo. stesso effetto.

Sei sicuro di non fare netstat -ntapinvece netstat ntap?

— Kyle Brandt,

Sono sicuro che stavo facendo netstat -ntap- proprio come ho scritto. poiché questo è il modo in cui vengono fornite le opzioni a netstat secondo la sua pagina man.

Nota a margine: ho appena controllato e sembra che netstat non riconosca le opzioni fornite senza "-".

4

Ciò si verificherà con processi del kernel come NFS, ma occasionalmente si verifica anche con app normali: RHEL 5 ha lo stesso comportamento.

# netstat -taupen | grep 30715
tcp        0      0 0.0.0.0:30715           0.0.0.0:*               LISTEN      66558      81467710   -

Si noti che lsof, d'altra parte, le parole correttamente:

# lsof -i:30715
AppName 1598 useracct   78u     IPv4           81467710                   TCP *:30715 (LISTEN)

— mikemaccana
fonte

3

198_141:~ # netstat  -anp|grep 33000
tcp        0      0 0.0.0.0:53000           0.0.0.0:*               LISTEN       -                   
198_141:~ # lsof -i:33000
COMMAND   PID USER   FD   TYPE     DEVICE SIZE NODE NAME
vsftpd  28147 root    3u  IPv4 4089990174       TCP *:33000 (LISTEN)
198_141:~ # id
uid=0(root) gid=100(users) groups=16(dialout),100(users)
198_141:~ #

nel mio caso, ci potrebbero essere due situazioni:

1) l'utente con privilegi normali non può vedere "netstat" quei processi avviati da root

2) alcuni processi vengono eseguiti nel kernel

— Yans Ruan
fonte

1

Per le connessioni stabilite, questo dovrebbe succedere solo per le connessioni che sono iniziate dallo spazio del kernel, come NFS o DRBD. Ovviamente le connessioni in attesa avrebbero potuto far morire il processo sotto di loro. Se non riesci a capire cosa sta causando una determinata connessione, incolla l'output e qualcuno può dirti di cosa si tratta.

— womble
fonte

Queste non sono sicuramente connessioni basate sul kernel in quanto si tratta di connessioni al database dall'applicazione.

Output di netstat -atnp | grep EST?

— womble

questo è il mio problema: le connessioni sono elencate in base al nome pid / programma che ho "-"

3

E mi piacerebbe vedere cosa sta realmente accadendo, piuttosto che una sua interpretazione.

— womble

Non posso mostrare l'intero output in quanto contiene nomi che potrebbero essere utilizzati per identificare l'ambiente. la linea per questa porta particolare è simile alla seguente: "tcp 0 0 localhost: 36949 localhost: 6543 STABILITO -"

1

Ho lo stesso comportamento e la mia ipotesi è che il comportamento di netstat potrebbe essere cambiato. Ad esempio, vedo la porta e il programma per "wget", ma non per i processi PHP di Apache, che sono i più importanti per me.

Soluzione alternativa: ho riscritto il mio script per utilizzare invece lsof (vedere il suggerimento sopra)

Pascal: hai eseguito questo comando con sudo o come root?

— Stefan Lasiewski,

0

Arrivo qui perché in questi giorni ho incontrato la stessa domanda su Ubuntu 18.04 LTS (netstat è la stessa versione netstat 1.42 (2001-04-15)), strano ancora nessuna risposta dopo 8 anni. Dopo aver cercato il codice sorgente di net-tools, potrei trovarlo.

Nel codice sorgente netstat:

tutte le cartelle di processo in / proc sono ripetute, ogni directory fd in / proc // fd viene controllata per costruire una mappa dall'inode socket al pid / progname.
quindi / proc / net / tcp viene controllato per ottenere informazioni sul socket tcp (dalla funzione tcp_info), incluso l'inode del socket.
quando si trasmettono le informazioni sul socket tcp, il pid / progname viene interrogato dalla mappa nel passaggio 1 tramite l'inode del socket. se non viene trovato nulla, "-" viene visualizzato.

Se il socket viene creato dopo la creazione della mappa, il pid / progname non verrà trovato nella mappa.

— zenkj
fonte