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 bien que les processus du noyau ne soient marqués d'aucune façon.
Merci encore à vous deux. 😉
Réponse acceptée :
netstat
Il y a un processus là-bas, 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 ça t'empêche de voir ça. Réexécutez simplement la commande mais préfixez-la en utilisant le sudo commande à 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 ne peuvent pas être identifiés, les informations sur les processus non détenus ne seront pas affichées, vous devrez ê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 ss ça ira. Vous devrez toujours utiliser sudo , et la sortie peut être un peu plus cryptée.
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 en savoir plus sur NFS, dans la réponse de @ derobert, qui en fait partie. Il y en a d'autres. J'ai des cas où j'utilise des tunnels ssh pour me reconnecter à des services tels que IMAP. Ceux-ci s'affichent également sans ID de processus.
Dans tous les cas, vous pouvez utiliser une forme plus détaillée de netstat ce qui pourrait apporter un éclairage supplémentaire sur 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 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 conduire à un processus.
Connexe :Surveillance des processus dans un environnement Linux ?Références
- Port vers PID