Solution 1 :
Avez-vous exécuté netstat et lsof en tant que root ou avec sudo ? Remarquez la dernière colonne :
netstat -ln --program
tcp 0 0 192.168.21.1:53 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
sudo netstat -ln --program
tcp 0 0 192.168.21.1:53 0.0.0.0:* LISTEN 2566/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2566/named
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 3125/sshd
À partir de la page de manuel de netstat :
Vous aurez également besoin des privilèges de superutilisateur pour voir ces informations sur les sockets que vous ne possédez pas.
Comment savez-vous qu'il n'y en a pas un en cours d'exécution ? Si le port est en cours d'utilisation, il est logique qu'il se ferme immédiatement avec une erreur "socket en cours d'utilisation". que se passe-t-il lorsque vous vous connectez par telnet au port ?
telnet localhost 5666
Solution 2 :
Les ports ouverts par le noyau n'apparaîtront pas avec le nom du programme. Certaines choses NFS et OCFS me viennent à l'esprit. C'est peut-être quelque chose comme ça ?
Ou cela pourrait être un bogue du noyau. Vérifiez les journaux du noyau pour OOPS et BUG.
Solution 3 :
exécutez 'netstat --tcp --udp --listening --program' en tant qu'utilisateur root . sinon, il ne donnera pas PID/Nom du programme
puis utilisez la commande kill -9 PID
Solution 4 :
J'ai en fait écrit un petit script shell pour aider à identifier ces questions occasionnelles :
#! /bin/bash
([ "$1" = "" ] || [ "$2" = "" ]) && echo "Usage: tracer <space> <port>" && exit 0
for i in `fuser -n $1 $2`
do
ps aux | grep $i | grep -v 'grep'
done
enregistrer sous /usr/local/bin/tracer ; sortie :
[email protected]:/usr/flows# tracer tcp 80
80/tcp:
root 27904 0.0 0.0 111668 3292 ? Ss Aug04 0:03 /usr/sbin/apache2 -k start
www-data 32324 0.0 0.0 335332 3560 ? Sl Aug05 0:00 /usr/sbin/apache2 -k start
www-data 32327 0.0 0.0 335324 3560 ? Sl Aug05 0:00 /usr/sbin/apache2 -k start
Vous aurez besoin des privilèges root pour l'utiliser
Solution 5 :
J'ai pu suivre le processus en obtenant son inode via netstat, puis en utilisant cet inode avec lsof. Voir ma réponse plus détaillée dans https://serverfault.com/a/847910/94376.