¿Cómo identificar un proceso que no tiene pid?

Tengo un proceso que escucha 2 puertos: 45136 / tcp y 37208 / udp (en realidad supongo que es el mismo proceso). Pero netstat no devuelve ningún pid:

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

Mismo resultado con "grep 37208".

También probé lsof:

lsof -i TCP:45136

Pero no devuelve nada. Es una nueva instalación de squeeze y realmente no sé qué podría ser este proceso. Alguna idea ?

RESPUESTA Gracias a sus comentarios descubrí de qué se trataba. Desinstalé nfs-server nfs-common (después de una búsqueda dkpg --get-selections | grep nfs) y el proceso desconocido desapareció. Aunque es extraño que los procesos del kernel no estén marcados de ninguna manera.

Gracias de nuevo a los dos. ;)

netstat

Hay un proceso allí, su ID de usuario simplemente no está al tanto de ver de qué se trata. Esta es una capa de protección provista por lsofeso que le impide ver esto. Simplemente vuelva a ejecutar el comando pero prefijelo usando el sudocomando en su lugar.

$ sudo netstat -antlp | grep 45136

Incluso hay una advertencia sobre esto en la salida de lsofen la parte superior.

(No se pudieron identificar todos los procesos, no se mostrará la información del proceso que no es de su propiedad, tendría que ser root para verlo todo).

Ejemplo

$ 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

Si no tienes suerte, netstatquizás sslo hagas. Aún necesitará usar sudo, y la salida puede ser un poco más críptica.

Ejemplo

$ 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))

¿La identificación del proceso todavía no está allí?

Hay casos en los que simplemente no hay un PID asociado al puerto TCP en uso. Puede leer sobre NFS, en la respuesta de @ derobert , que es una de ellas. Hay otros. Tengo instancias en las que estoy usando túneles ssh para conectarme a servicios como IMAP. Estos también se muestran sin una ID de proceso.

En cualquier caso, puede usar una forma más detallada netstatque podría arrojar luz adicional sobre qué proceso está usando un puerto TCP.

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

Ejemplo

$ 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  -             

Si observa que la salida incluye INODES para que podamos realizar un seguimiento del proceso utilizando esta información.

$ find -inum 152555007

Lo que le mostrará un archivo que podría llevarlo a un proceso.

Referencias

• Puerto a PID

Otra opción es que el socket no pertenece a un proceso, pertenece al kernel. Un ejemplo común de esto es 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      -               

No estoy seguro de una buena manera, en general, de identificarlos. En el caso particular de NFS, rpcinfoa menudo podrá decirnos:

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

Desafortunadamente, eso solo funciona para IPv4. Para obtener v6, debe dejarlo -p, que luego muestra los números de puerto de una manera tonta: como dos octetos adicionales de dirección IP. El puerto 55607 se convierte así en 217.55 (porque 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