Un fichier refuse de se démonter, un port est déjà utilisé, un service ne redémarre pas proprement… dans ces moments-là, lsof fait gagner du temps. La commande liste les fichiers ouverts, mais sous Linux, un socket réseau, une bibliothèque, un répertoire ou un périphérique peuvent aussi être vus comme des fichiers.
L’idée n’est pas de tuer le premier PID affiché. Je m’en sers plutôt pour répondre à une question simple : quel processus tient encore la ressource, et est-ce que je dois fermer l’application, arrêter un service proprement ou intervenir plus franchement ?
Installer lsof avant de chercher le mauvais coupable
Sur beaucoup de distributions serveur, lsof est déjà présent. Si la commande manque, installez-la avec le gestionnaire de paquets de votre distribution.
command -v lsof
sudo apt install lsof
sudo dnf install lsof
sudo pacman -S lsofSur un serveur de production, je vous conseille de commencer par une commande très ciblée. Un lsof lancé trop largement peut sortir énormément de lignes, surtout sur une machine qui héberge du web, une base de données ou beaucoup de sessions SSH.
Voir quel processus utilise un fichier précis
Le cas le plus simple consiste à donner à lsof le chemin du fichier. C’est utile quand un log reste ouvert, quand un fichier semble impossible à supprimer, ou quand vous voulez savoir quel programme écrit encore dedans.
sudo lsof /var/log/syslog
sudo lsof /var/log/nginx/access.logLes colonnes importantes sont généralement COMMAND, PID, USER, FD et NAME. Le PID vous donne l’identifiant du processus. Avant toute action, vérifiez-le avec ps.
ps -fp 1234
readlink -f /proc/1234/exeSi vous voyez un service connu, ne partez pas directement sur kill. Regardez d’abord son état avec systemctl, puis arrêtez ou redémarrez le service proprement si c’est bien lui le responsable.
systemctl status nginx --no-pager
sudo systemctl restart nginxRetrouver le programme qui écoute sur un port
Autre scénario très courant : vous lancez un service, et il échoue parce que le port est déjà occupé. Au lieu de supposer que c’est Nginx, Apache, Docker ou un vieux processus oublié, interrogez le port.
sudo lsof -iTCP:80 -sTCP:LISTEN -P -n
sudo lsof -iTCP:443 -sTCP:LISTEN -P -n
sudo lsof -i :8080 -P -nL’option -P évite la conversion des ports en noms de services. L’option -n évite la résolution DNS. C’est plus rapide et plus lisible quand vous êtes en diagnostic.
Pour afficher tous les ports TCP en écoute, vous pouvez lancer :
sudo lsof -iTCP -sTCP:LISTEN -P -nPour un audit plus large des ports ouverts, ss reste souvent plus pratique. Mais quand vous voulez relier vite un port à un PID et à un binaire, lsof est très direct.
Trouver ce qui empêche un démontage
Si umount répond que la cible est occupée, ne forcez pas à l’aveugle. Vérifiez d’abord quel processus utilise encore le point de montage.
findmnt /mnt/backup
sudo lsof +D /mnt/backup+D descend dans le dossier et peut être lent sur une grosse arborescence. Sur un partage réseau ou un disque avec beaucoup de fichiers, commencez si possible par le dossier le plus précis. Si le problème vient d’un shell resté ouvert dans ce répertoire, un simple changement de dossier ou la fermeture de la session suffit parfois.
Pour les montages persistants, notamment ceux déclarés dans /etc/fstab, gardez aussi un œil sur les options de montage. J’ai détaillé ce point dans le guide sur fstab sous Linux.
Décider quoi faire du PID trouvé
Un PID affiché par lsof n’est pas automatiquement un processus à tuer. C’est le piège classique. Avant de couper quoi que ce soit, identifiez le service, l’utilisateur et le contexte.
ps -fp 1234
systemctl status nginx --no-pager
journalctl -u nginx -n 50 --no-pagerSi c’est une application utilisateur, fermez-la proprement. Si c’est un service systemd, utilisez plutôt systemctl stop ou systemctl restart. Si vous devez vraiment envoyer un signal, commencez par TERM. KILL doit rester le dernier recours, surtout avec une base de données, un transfert de fichiers ou une écriture disque en cours.
sudo kill -TERM 1234
sleep 2
ps -p 1234
sudo kill -KILL 1234Si vous voulez le détail sur les signaux et les erreurs à éviter, l’article sur kill sous Linux complète bien cette partie.
Les options lsof que j’utilise le plus
Dans la pratique, je garde surtout quelques variantes. Elles couvrent la majorité des diagnostics sans transformer la sortie en mur illisible.
sudo lsof /chemin/fichier: savoir qui tient un fichier précis.sudo lsof +D /chemin/dossier: chercher dans un dossier, avec prudence sur les grosses arborescences.sudo lsof -iTCP:PORT -sTCP:LISTEN -P -n: identifier le processus qui écoute sur un port TCP.sudo lsof -p 1234: afficher les fichiers ouverts par un processus connu.sudo lsof -u utilisateur: regarder ce qu’un utilisateur a ouvert.
La page de manuel de lsof va beaucoup plus loin, mais ces commandes suffisent déjà pour un dépannage propre. Pour les signaux, la page de manuel de kill permet aussi de vérifier le comportement attendu avant de couper un processus sensible.
Vérifier que la ressource est vraiment libérée
Après fermeture du programme, arrêt du service ou signal envoyé, relancez la commande initiale. C’est le seul moyen de savoir si le fichier, le port ou le point de montage est réellement libre.
sudo lsof /var/log/nginx/access.log
sudo lsof -iTCP:80 -sTCP:LISTEN -P -n
sudo lsof +D /mnt/backupSi un service repart en boucle, regardez les journaux au lieu de relancer dix fois la même commande. tail peut aider sur un fichier de log précis, et journalctl reste plus adapté pour un service systemd.
journalctl -u nginx -n 80 --no-pager
journalctl -u nginx -fMon réflexe est simple : lsof pour identifier, les logs pour comprendre, puis une action propre. C’est moins spectaculaire qu’un kill -9, mais sur un serveur, c’est justement ce qu’on veut.