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 cela ne renvoie rien. C'est une nouvelle installation de Squeeze et je ne sais vraiment pas quel 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 cependant, les processus du noyau ne sont en aucun cas marqués.
Merci encore à vous deux. ;)
netstat
Il y a un processus, votre ID utilisateur n'est tout simplement pas au courant de ce que c'est. Il s'agit d'une couche de protection fournie par lsof qui vous empêche de voir cela. Réexécutez simplement la commande mais préfixez-la en utilisant la commande Sudo à la place.
$ Sudo netstat -antlp | grep 45136
Il y a même un avertissement à ce sujet dans la sortie de lsof en haut.
(Tous les processus n'ont pas pu être identifiés, les informations sur les processus n'appartenant pas à eux 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 netstat peut-être que ss fera l'affaire. Vous devrez toujours 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 réponse de @ derobert , qui est l'un des Il y en a d'autres. J'ai des cas où j'utilise des tunnels ssh pour me reconnecter à des services tels que IMAP. Ils apparaissent également sans ID de processus.
Dans tous les cas, vous pouvez utiliser une forme plus verbeuse de netstat qui pourrait apporter un éclairage supplémentaire sur le processus qui utilise finalement un port TCP 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 des INODES afin que nous puissions revenir en arrière dans le processus en utilisant ces informations.
$ find -inum 152555007
Ce qui vous montrera un fichier qui pourrait vous mener à un processus.
Références
Une autre option est que le socket n'appartient pas à un processus, il appartient au noyau. Un exemple courant de cela 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 d'un bon moyen, en général, de les identifier. Dans le cas particulier de NFS, rpcinfo pourra 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 arrêter -p, qui affiche ensuite les numéros de port de manière ridicule: comme 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