Comment identifier un processus qui n'a pas de pid?

J'ai un processus qui écoute 2 ports: 45136 / TCP et 37208 / UDP (en fait, je suppose que c'est le même processus). Mais netstat ne renvoie aucun pid:

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

Même résultat avec "grep 37208".

J'ai aussi essayé lsof:

lsof -i TCP:45136

Mais ça ne retourne rien. C'est une nouvelle installation de squeeze et je ne sais vraiment pas ce que pourrait être ce processus. Une idée ?

RÉPONSE Grâce à vos commentaires, j'ai découvert ce que c'était. J'ai désinstallé nfs-server nfs-common (après une recherche dkpg --get-selections | grep nfs) et le processus inconnu a disparu. Étrange que les processus du noyau ne soient marqués d'aucune façon.

Merci encore à vous deux. ;)

netstat

Il y a un processus là-bas, votre userid n'est tout simplement pas au courant de voir ce que c'est. Ceci est une couche de protection fournie par lsofqui vous empêche de voir cela. Il suffit de réexécuter la commande mais de la préfixer avec la sudocommande.

$ sudo netstat -antlp | grep 45136

Il y a même un avertissement à ce sujet dans la sortie du lsofhaut.

(Tous les processus n'ont pas pu être identifiés, les informations sur les processus n'appartenant pas à l'utilisateur ne seront pas affichées. Vous devez être root pour tout voir.)

Exemple

$ 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 vous n'avez pas de chance avec netstatpeut ss- être va faire. Vous aurez toujours besoin d'utiliser sudo, et la sortie peut être un peu plus cryptique.

Exemple

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

L'ID de processus n'est toujours pas là?

Il y a des cas où il n'y a tout simplement pas de PID associé au port TCP utilisé. Vous pouvez lire sur NFS, dans la réponse de @ derobert , qui en fait partie. Il y en a d'autres. Il arrive que j'utilise des tunnels SSH pour me reconnecter à des services tels qu'IMAP. Ceux-ci apparaissent aussi sans identifiant de processus.

Dans tous les cas, vous pouvez utiliser une forme plus détaillée netstatqui pourrait éclairer davantage le processus qui utilise finalement un port TCP.

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

Exemple

$ 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 vous remarquez que la sortie inclut INODES, nous pourrions revenir en arrière dans le processus en utilisant cette information.

$ find -inum 152555007

Ce qui vous montrera un fichier qui pourrait vous mener à un processus.

Références

• Port vers PID

Une autre option est que le socket n'appartient pas à un processus, mais au noyau. Un exemple courant est 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      -               

Je ne suis pas sûr que ce soit un bon moyen, en général, de les identifier. Dans le cas particulier de NFS, on rpcinfopourra souvent nous dire:

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

Malheureusement, cela ne fonctionne que pour IPv4. Pour obtenir la v6, vous devez vous arrêter -p, ce qui affiche ensuite les numéros de port de manière idiote: Deux octets supplémentaires d’adresse IP. Le port 55607 devient ainsi 217,55 (car 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