Scénario 1 : Libérer de l'espace disque après la suppression de fichiers volumineux

Dans les systèmes Unix/Linux, lorsqu'un fichier est supprimé par une commande comme rm, l'espace disque n'est pas immédiatement récupéré si un processus actif maintient ce fichier ouvert. Le système d'exploitation attend que tous les descripteurs de fichiers associés soient fermés avant de libérer réellement les blocs de données. Cela explique pourquoi df peut afficher un disque plein alors que du ne trouve aucun fichier volumineux.

Voici une démonstration de ce comportement avec un script de simulation :

# Création du script de simulation : generator.sh
#!/bin/bash
counter=0
while [ $counter -lt 600 ]
do
    echo "Génération de flux de données système..." >> app_runtime.log
    sleep 1
    ((counter++))
done

# Exécution en arrière-plan
sh generator.sh &

# Suppression du fichier log alors que le script tourne encore
rm app_runtime.log

# Vérification de l'état du fichier avec lsof
# On cherche les fichiers marqués comme (deleted)
lsof | grep deleted

Dans la sortie de lsof, vous verrez une ligne similaire à celle-ci :

COMMAND   PID  USER   FD   TYPE  DEVICE  SIZE/OFF    NODE  NAME
sh      12345  root    1w   REG   253,1      4096  526093  /root/app_runtime.log (deleted)

Pour récupérer l'espace, vous devez soit arrêter le processus identifié par son PID (ici 12345), soit vider le descripteur de fichier via l'interface /proc.

Scénario 2 : Localiser la destination des flux de sortie d'un processus

Il arrive souvant de devoir intervenir sur un serveur où un processus tourne sans que l'on sache où ses logs sont écrits. lsof permet de mapper les descripteurs de fichiers standard (0: stdin, 1: stdout, 2: stderr) vers des fichiers réels.

# Trouver le PID du processus concerné
ps -ef | grep "mon_application"

# Inspecter les fichiers ouverts par ce PID
lsof -p 15280

L'analyse des colonnes FD (File Descriptor) est cruciale :

• 1w indique la sortie standard (stdout) en mode écriture.
• 2w indique la sortie d'erreur (stderr).

Le chemin affiché dans la colonne "NAME" révèle l'emplacement exact des logs en cours d'écriture.

Scénario 3 : Identifier l'application utilisant un port réseau

Lorsqu'un service refuse de démarrer car un port est déjà utilisé, lsof est l'outil le plus rapide pour identifier le conflit.

# Vérifier quel processus écoute sur le port 8080
lsof -i :8080

Exemple de sortie :

COMMAND   PID  USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
java    18290  apps   45u  IPv4  128934      0t0  TCP *:8080 (LISTEN)

Scénario 4 : Résoudre l'erreur "Device is busy" lors du démontage

Le démontage d'une partition (umount) échoue si un utilisateur ou un processus a un répertoire de travail actuel ou un fichier ouvert sur ce point de montage.

# Tentative de démontage
umount /data/storage
# Sortie : umount: /data/storage: device is busy.

# Identifier le bloqueur
lsof /data/storage

Une fois le processus identifié, vous pouvez demander aux utilisateurs de quitter le répertoire ou terminer le processus proprement avant de relancer le démontage.

Scénario 5 : Exploration via le système de fichiers /proc

La commande lsof extrait ses informations du répertoire /proc. Chaque processus possède un sous-répertoire fd contenant des liens symboliques vers ses fichiers ouverts.

# Liste des descripteurs pour un processus donné
ls -l /proc/12345/fd

Cette méthode est utile dans les environnements restreints où lsof n'est pas installé. Les liens symboliques pointent directement vers les fichiers, sockets ou pipes utilisés par le processus. Par exemple, une entrée 3 -> /var/log/syslog signifie que le descripteur 3 est lié au fichier syslog.

Comparaison entre /proc et lsof

Bien que /proc soit la source de vérité, lsof agrège ces données brutes avec des informations sur le type de nœud (NODE), la taille des fichiers et l'état des sockets réseau (TCP/UDP), offrant ainsi une vue synthétique indispensable pour le dépannage rapide en production.