Come identificare un processo che non ha pid?


47

Ho un processo che ascolta 2 porte: 45136 / tcp e 37208 / udp (in realtà suppongo che sia lo stesso processo). Ma netstat non restituisce alcun pid:

netstat -antlp | grep 45136
tcp        0      0 0.0.0.0:45136           0.0.0.0:*           LISTEN      - 

Stesso risultato con "grep 37208".

Ho provato anche lsof:

lsof -i TCP:45136

Ma non restituisce nulla. È una nuova installazione di squeeze e davvero non so quale potrebbe essere questo processo. Qualche idea ?

RISPOSTA Grazie ai tuoi commenti ho scoperto di cosa si trattava. Ho disinstallato nfs-server nfs-common (dopo una ricerca di dkpg --get-selections | grep nfs) e il processo sconosciuto è scomparso. Strano però che i processi del kernel non siano contrassegnati in alcun modo.

Grazie ancora ad entrambi. ;)

Risposte:


57

netstat

C'è un processo lì, il tuo userid non è al corrente di vedere di cosa si tratta. Questo è un livello di protezione fornito da lsofciò che ti impedisce di vedere questo. È sufficiente eseguire nuovamente il comando ma prefissarlo utilizzando sudoinvece il comando.

$ sudo netstat -antlp | grep 45136

C'è anche un avvertimento a riguardo nell'output di lsofin alto.

(Non tutti i processi potrebbero essere identificati, le informazioni sui processi non di proprietà non verranno mostrate, dovresti essere root per vederle tutte.)

Esempio

$ netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      -                   

$ sudo netstat -antlp | grep 0:111
tcp        0      0 0.0.0.0:111       0.0.0.0:*     LISTEN      1248/rpcbind

ss

Se non hai fortuna, netstatforse sslo farà. Dovrai comunque utilizzarlo sudoe l'output può essere un po 'più enigmatico.

Esempio

$ ss -apn|grep :111
LISTEN     0      128         :::111             :::*     
LISTEN     0      128          *:111              *:*     

$ sudo ss -apn|grep :111
LISTEN     0      128         :::111             :::*      users:(("rpcbind",1248,11))
LISTEN     0      128          *:111              *:*      users:(("rpcbind",1248,8))

ID processo ancora non presente?

Ci sono casi in cui semplicemente non esiste un PID associato alla porta TCP in uso. Puoi leggere di NFS, nella risposta di @derobert , che è una di queste. Ce ne sono altri Ho casi in cui sto usando tunnel ssh per riconnettermi a servizi come IMAP. Questi vengono visualizzati anche senza un ID processo.

In ogni caso è possibile utilizzare una forma più dettagliata netstatche potrebbe far luce su quale processo sta usando una porta TCP.

$ netstat --program --numeric-hosts --numeric-ports --extend

Esempio

$ netstat --program --numeric-hosts --numeric-ports --extend |grep -- '-' | head -10
Proto Recv-Q Send-Q Local Address               Foreign Address             State       User       Inode      PID/Program name   
tcp        0      0 192.168.1.103:936           192.168.1.3:60526           ESTABLISHED root       160024310  -                   
tcp        0      0 192.168.1.1:2049            192.168.1.3:841             ESTABLISHED sam        159941218  -                   
tcp        0      0 127.0.0.1:143               127.0.0.1:57443             ESTABLISHED dovecot    152567794  13093/imap-login    
tcp        0      0 192.168.1.103:739           192.168.1.3:2049            ESTABLISHED root       160023970  -                   
tcp        0      0 192.168.1.103:34013         192.168.1.3:111             TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:46110             127.0.0.1:783               TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.102:54891         107.14.166.17:110           TIME_WAIT   root       0          -                   
tcp        0      0 127.0.0.1:25                127.0.0.1:36565             TIME_WAIT   root       0          -                   
tcp        0      0 192.168.1.1:2049            192.168.1.6:798             ESTABLISHED tammy      152555007  -             

Se noti che l'output include INODES in modo da poter tornare indietro nel processo utilizzando queste informazioni.

$ find -inum 152555007

Che ti mostrerà un file che potrebbe condurti a un processo.

Riferimenti


@derobert - Stavo pensando che fossero discussioni.
slm

I thread @slm (userspace) hanno PID.
derobert,

@derobert - questo è quello che pensavo, ma per essere sicuro è stato un doppio controllo.
slm

@derobert - Ho trovato questo: "Il kernel Linux stesso fornisce il server NFS (aka" knfsd "). Quindi non esiste alcun processo associato perché il kernel non è un processo."
slm

@JohnDoe - potrebbe essere che siano correlati a NFS.
slm

16

Un'altra opzione è che il socket non appartiene a un processo, appartiene al kernel. Un esempio comune di ciò è NFS.

Watt:~# netstat -ltp | egrep -- '-[[:space:]]*$'
tcp        0      0 *:nfs                   *:*                     LISTEN      -               
tcp        0      0 *:48131                 *:*                     LISTEN      -               
tcp6       0      0 [::]:55607              [::]:*                  LISTEN      -               
tcp6       0      0 [::]:nfs                [::]:*                  LISTEN      -               

Non sono sicuro di un buon modo, in generale, per identificarli. Nel caso particolare di NFS, rpcinfosarà spesso in grado di dirci:

anthony@Watt:~$ rpcinfo -p | grep 48131
    100021    1   tcp  48131  nlockmgr
    100021    3   tcp  48131  nlockmgr
    100021    4   tcp  48131  nlockmgr

Sfortunatamente, funziona solo per IPv4. Per ottenere la v6, devi smettere -p, che quindi mostra i numeri di porta in modo sciocco: come due ottetti aggiuntivi di indirizzo IP. La porta 55607 diventa quindi 217,55 (perché 217  × 256 +  55  = 55607):

anthony@Watt:~$ rpcinfo  | grep -i 217.55
    100021    1    tcp6      ::.217.55              nlockmgr   superuser
    100021    3    tcp6      ::.217.55              nlockmgr   superuser
    100021    4    tcp6      ::.217.55              nlockmgr   superuser

1
Grazie per aver sottolineato rpcinfo -pfunziona solo per IPv4
youfu
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.