Espace disponible, mais Linux répond No space left on device

Situation critique : L’application ne crée plus de fichiers. Un gros journal a été supprimé, mais l’espace libre n’augmente pas. Ou le rapport indique encore de la place tandis que No space left on device persiste. Avant de supprimer davantage, identifiez la ressource réellement épuisée.

Examiner le chemin qui échoue

Le chemin /var ci-dessous est un exemple ; remplacez-le par le répertoire où l’application échoue réellement. Ces commandes servent au diagnostic sur Linux :

findmnt -T /var
df -h /var
df -i /var
sudo lsof +L1

df -h indique l’usage des blocs de données ; df -i, celui des inodes. Sur les systèmes de fichiers concernés, des inodes épuisés empêchent la création de fichiers même si des blocs restent libres. Le chemin applicatif peut être sur un autre montage ; la capacité de la racine ne suffit pas.

Si les inodes sont épuisés

Limitez le producteur de nombreux petits fichiers, par exemple une tâche défectueuse créant un temporaire à chaque échec. Nettoyez un répertoire identifié en connaissant responsable et rétention. Un cache reconstructible n’est ni une donnée principale, ni une file de travail, ni un fichier transactionnel.

Déplacer des fichiers dans le même système de fichiers ne libère généralement pas d’inodes. Réduisez les fichiers réellement inutiles sur ce système au lieu de réorganiser seulement les dossiers. Si la production continue, le nettoyage ne fait que gagner un court délai.

Si le fichier supprimé reste ouvert

lsof +L1 peut montrer des fichiers ouverts ayant moins d’un lien. Reliez un résultat volumineux et pertinent au PID et au service propriétaire. Le processus peut conserver le fichier supprimé ; enlever son nom ne libère pas nécessairement tous ses blocs immédiatement.

S’il s’agit du journal du service, cherchez sa procédure documentée de réouverture. À défaut, un redémarrage contrôlé de ce service, avec impact compris, peut libérer le descripteur. La mention « deleted » seule ne justifie pas de tuer un processus. Ne réparez pas des fichiers de base de données en manipulant /proc ou en tronquant des descripteurs.

Vérifier que l’intervention est terminée

Contrôlez de nouveau capacité et inodes sur le même chemin. Testez une petite création et écriture autorisées depuis l’application, puis observez la croissance. Si les preuves ne correspondent à aucun cas, examinez séparément quotas, système en lecture seule et stockage ; n’attribuez pas systématiquement ENOSPC aux journaux.

La décision utile : Avant de supprimer encore, déterminez si les blocs manquent, si les inodes sont épuisés ou si un processus conserve l’espace d’un fichier supprimé.

Références techniques: GNU / df · lsof.