Résoudre No space left on device sous Linux : espace disque, inodes et fichiers supprimés

EdwardMoon

Lorsque Linux affiche No space left on device, on pense immédiatement à un disque plein. Pourtant, l'erreur peut aussi provenir d'inodes épuisés, de fichiers supprimés encore ouverts par un processus, d'un montage absent ou de journaux qui grossissent rapidement.

Supprimer des fichiers avec rm -rf avant d'identifier la cause peut détruire les journaux utiles au diagnostic ou aggraver une interruption de service. Ce guide propose une démarche de diagnostic et des corrections adaptées aux serveurs Linux courants, notamment Rocky Linux, RHEL, CentOS et Ubuntu.

No space left on device : cinq commandes à exécuter d'abord

Si le temps presse, commencez par ces vérifications dans l'ordre. Remplacez /path par un répertoire existant sur le même système de fichiers que le chemin en erreur. Si le fichier cible n'existe pas parce que sa création a échoué, utilisez le répertoire parent existant le plus proche.

# 1. Identifier le système de fichiers du chemin en erreur
findmnt -T /path

# 2. Vérifier l'utilisation des blocs du système de fichiers
df -hT /path

# 3. Vérifier l'utilisation des inodes
df -i /path

# 4. Repérer les gros répertoires du même système de fichiers
sudo du -xhd1 /path 2>/dev/null | sort -h

# 5. Repérer les fichiers supprimés encore ouverts par un processus
sudo lsof +L1 2>/dev/null

Attention : du et find peuvent générer beaucoup d'entrées-sorties sur un serveur contenant de nombreux fichiers. Limitez le périmètre et surveillez l'impact sur les applications en production.

Causes fréquentes de No space left on device

1. Vérifier l'utilisation des blocs disque

df -hT
df -hT /var/log

df affiche, pour chaque système de fichiers, la taille totale, l'espace utilisé et disponible, le pourcentage d'utilisation et le point de montage. -h emploie des unités lisibles et -T indique le type, par exemple XFS ou ext4. Examinez Avail, l'espace disponible pour les utilisateurs ordinaires, autant que Use%. Avec les blocs réservés d'ext4, root peut encore disposer d'espace lorsque les autres utilisateurs n'en ont plus.

Ne vous limitez pas à la liste générale. Indiquez un répertoire existant sur le même système de fichiers que le chemin où l'écriture échoue. Si l'application ne peut pas écrire dans /data/app.log, le fichier peut ne jamais avoir été créé : examinez alors son répertoire parent existant, /data.

findmnt -T /data
df -hT /data

Même si le système de fichiers racine dispose d'espace, la création de fichiers dans /data échouera si ce répertoire se trouve sur un système de fichiers distinct et plein.

2. Vérifier l'utilisation des inodes

df -i
df -i /var

Un inode contient les métadonnées d'un fichier : permissions, propriétaire, taille, horodatages et emplacement des données. Un très grand nombre de petits fichiers peut épuiser les inodes avant l'espace disque. ext4 fixe le nombre d'inodes à la création du système de fichiers, tandis que XFS les alloue dynamiquement. XFS peut néanmoins refuser la création de fichiers si l'espace destiné aux données ou aux métadonnées manque : examinez donc df -i avec df -hT.

Si IUse% atteint 100 %, supprimer de nombreux petits fichiers inutiles sera plus efficace que supprimer quelques gros fichiers. La commande suivante repère les répertoires contenant beaucoup de fichiers.

# Repérer les répertoires contenant beaucoup de fichiers sur le système de fichiers de /var
sudo find /var -xdev -type f -printf '%h\n' 2>/dev/null \
  | sort | uniq -c | sort -nr | head -n 30

Les fichiers de session, caches applicatifs, files d'attente de messagerie et fichiers temporaires créés en masse sont des causes fréquentes. Vérifiez les obligations de conservation et l'impact sur le service avant de les supprimer.

3. Repérer les répertoires et fichiers volumineux

Si le système de fichiers racine est plein, examinez d'abord les répertoires du premier niveau, puis descendez dans les chemins les plus volumineux.

sudo du -xhd1 / 2>/dev/null | sort -h
sudo du -xhd1 /var 2>/dev/null | sort -h
sudo du -xhd1 /var/log 2>/dev/null | sort -h

-x évite de parcourir d'autres systèmes de fichiers. -d1 limite les totaux affichés au premier niveau sous le répertoire de départ. Les fichiers et répertoires plus profonds restent parcourus pour calculer ces totaux : cette option seule ne réduit donc ni le parcours ni les entrées-sorties. Consultez le manuel officiel de GNU du pour le détail des options.

Voici un exemple pour trouver les fichiers de plus de 1 Go sur un système de fichiers donné.

sudo find /var -xdev -type f -size +1G \
  -printf '%s %p\n' 2>/dev/null \
  | sort -nr | head -n 30

Les emplacements à examiner comprennent /var/log, /var/cache, /tmp, /home, /opt et /var/lib/docker. Toutefois, supprimer manuellement des fichiers dans /var/lib peut endommager des bases de données ou des moteurs de conteneurs. Utilisez la procédure de nettoyage prise en charge par chaque service.

4. Rechercher les fichiers supprimés encore ouverts

Sous Linux, supprimer le nom d'un fichier ne libère pas immédiatement ses blocs si un processus le conserve ouvert. Le fichier disparaît de l'arborescence et du ne peut plus le compter, mais df continue à considérer l'espace comme utilisé jusqu'à la fermeture du descripteur.

sudo lsof +L1 2>/dev/null

# Afficher les éléments les plus volumineux en premier
sudo lsof +L1 2>/dev/null \
  | awk 'NR>1 {print $7, $1, $2, $4, $9}' \
  | sort -nr | head -n 30

Examinez le nom du processus, son PID, le descripteur et la taille dans la sortie. Pour récupérer l'espace, redémarrez le service selon sa procédure normale ou demandez à l'application de rouvrir le fichier.

sudo systemctl restart 서비스명
sudo lsof +L1 2>/dev/null
df -hT

Sur un serveur de production, vérifiez d'abord la redondance et l'impact sur le service. Tuer un processus avec kill -9 ou tronquer de force /proc/PID/fd sans comprendre la cause peut entraîner des pertes de données et des interruptions ; ce ne sont pas des premières mesures appropriées.

5. Réduire l'espace occupé par le journal systemd

journalctl --disk-usage

Si le journal systemd occupe beaucoup d'espace, vous pouvez supprimer les anciens fichiers archivés selon leur taille ou leur âge.

# Effectuer une rotation, puis ramener les journaux archivés à 500 Mo maximum
sudo journalctl --rotate --vacuum-size=500M

# Supprimer les journaux archivés de plus de 14 jours
sudo journalctl --vacuum-time=14d

Les options --vacuum-* agissent sur les fichiers de journal archivés. Combinez-les avec --rotate pour effectuer d'abord une rotation des fichiers actifs et récupérer de l'espace immédiatement.

Pour éviter une récidive, fixez une taille maximale adaptée à votre distribution et à votre politique d'exploitation.

# /etc/systemd/journald.conf.d/10-size-limit.conf
[Journal]
SystemMaxUse=1G
RuntimeMaxUse=256M

sudo systemctl restart systemd-journald
journalctl --disk-usage

Pour comprendre la structure des services systemd, consultez Créer un service systemd et comprendre ses composants.

6. Un montage absent remplit le système de fichiers racine

Si /data doit résider sur un stockage séparé mais n'est pas monté à cause d'un problème de démarrage ou de réseau, une application peut continuer à écrire à cet emplacement sur le système de fichiers racine.

findmnt -T /data
lsblk -f
systemctl --failed
journalctl -b -u '*.mount'

Arrêtez les écritures applicatives et rétablissez le montage prévu avant de supprimer des fichiers. L'examen de fichiers masqués sous un montage nécessite une procédure de maintenance tenant compte de l'impact sur le service et de la cohérence des données.

Pourquoi df et du affichent des valeurs différentes

df mesure l'utilisation à partir des blocs alloués par le système de fichiers. du parcourt les fichiers accessibles dans l'arborescence actuelle. Leurs résultats peuvent donc différer pour plusieurs raisons.

• Fichiers supprimés encore ouverts par un processus
• Métadonnées et espace réservé du système de fichiers
• Répertoires illisibles par du faute de permissions
• Autres systèmes de fichiers montés sous le chemin de départ
• Snapshots et blocs partagés dans les systèmes de fichiers à copie sur écriture

Si l'écart entre df et du est important, commencez par lsof +L1 et la configuration des montages.

Procédure de rétablissement en production

1. Identifier le chemin en erreur : déterminez le véritable emplacement d'écriture de l'application et son système de fichiers.
2. Arrêter la croissance : interrompez d'abord sa cause, par exemple une journalisation excessive ou une tâche répétitive.
3. Préserver les éléments de diagnostic : sauvegardez ailleurs les journaux et les informations d'état nécessaires avant le nettoyage.
4. Utiliser les outils pris en charge : privilégiez logrotate, le nettoyage des journaux systemd et les fonctions de nettoyage du cache de l'application.
5. Vérifier le rétablissement : contrôlez à nouveau l'espace disque, les inodes, la création de fichiers, l'état des services et les journaux applicatifs.

df -hT /path
df -i /path
touch /path/.write-test && rm -f /path/.write-test
systemctl --failed

Prévenir les récidives

• Surveillez l'utilisation des inodes en plus de l'espace disque.
• Définissez des seuils distincts d'avertissement et d'alerte critique, et suivez la vitesse de croissance.
• Configurez logrotate ou une politique de rétention propre à l'application.
• Limitez la taille et la durée de conservation du journal systemd selon votre politique d'exploitation.
• Utilisez les fonctions de nettoyage fournies par Docker, les bases de données et les logiciels de sauvegarde.
• Séparez /var/log, les données applicatives et les sauvegardes afin qu'une croissance localisée menace moins l'ensemble du système.
• Configurez les dépendances et les vérifications préalables pour empêcher une application d'écrire sur le disque local lorsqu'un montage requis est absent.

Questions fréquentes

Pourquoi No space left on device apparaît-il alors qu'il reste de l'espace ?

Vérifiez d'abord les inodes et le système de fichiers du chemin réellement concerné. La création peut échouer malgré l'espace affiché par df -h si df -i atteint 100 % ou si un autre point de montage est plein.

Pourquoi l'utilisation affichée par df ne baisse-t-elle pas après la suppression d'un journal ?

Un processus conserve probablement le fichier supprimé ouvert. Identifiez-le avec lsof +L1, puis redémarrez normalement le service ou demandez-lui de rouvrir ses fichiers pour libérer l'espace.

Puis-je supprimer tout le contenu de /var/log ?

Ce n'est pas recommandé. Vous risquez de perdre des éléments de diagnostic et des traces d'audit, et certaines applications peuvent ne pas avoir les droits nécessaires pour recréer leurs journaux. Utilisez logrotate, le nettoyage journalctl ou la fonction prévue par le produit.

Que faire si du est trop lent ?

-d1 limite uniquement la profondeur d'affichage ; les fichiers situés plus bas restent parcourus. Commencez par limiter la recherche au système de fichiers concerné et aux répertoires suspects. -x évite de parcourir d'autres systèmes de fichiers. Conservez les résultats pour ne pas répéter le même parcours et privilégiez les périodes de faible activité d'entrées-sorties sur les serveurs contenant beaucoup de fichiers.

Conclusion

La résolution de No space left on device sous Linux ne doit pas commencer par des suppressions. Identifiez le système de fichiers avec findmnt, vérifiez les blocs avec df -hT et les inodes avec df -i, puis examinez les répertoires avec du et les fichiers supprimés encore ouverts avec lsof +L1.

Une fois la cause identifiée, appliquez la mesure appropriée : adapter la rétention des journaux, redémarrer un service ou rétablir un montage. Vous limiterez ainsi les pertes de données et les incidents répétés.

Références

• GNU Coreutils: df invocation
• GNU Coreutils: du invocation
• Linux manual: inode(7)
• Linux manual: lsof(8)
• Linux manual: journalctl(1)