« PHP Warning: session_start(): open(/var/lib/php/sessions/sess_xxxx, O_RDWR) failed: No space left on device » : ce message, qui apparaît soudainement dans les journaux PHP en pleine période de forte affluence, ne veut pas nécessairement dire que le disque du serveur est plein au sens où on l’imagine d’abord. Il peut aussi signaler un quota d’inodes atteint, un problème bien différent qui demande un diagnostic distinct.
Ce warning touche en général des sites WordPress qui s’appuient sur des extensions utilisant les sessions PHP natives, par exemple pour un panier WooCommerce ou un système de connexion personnalisé, plutôt que sur les mécanismes propres à WordPress qui n’utilisent pas les sessions PHP par défaut. Comprendre d’où vient la saturation permet d’agir vite, sans déconnecter les visiteurs qui naviguent activement sur le site.
Distinguer disque plein et quota d’inodes atteint
Le message d’erreur est identique dans les deux cas, mais la cause et le traitement diffèrent totalement. La première vérification consiste à contrôler l’espace disque disponible sur la partition qui héberge le répertoire de sessions :
df -h /var/lib/php/sessions
Si l’espace disque restant est correct, il faut vérifier le nombre d’inodes disponibles, car un système de fichiers peut se retrouver à court d’inodes bien avant d’être plein en octets, notamment lorsque des centaines de milliers de petits fichiers de session s’accumulent :
df -i /var/lib/php/sessions
Repérer l’accumulation de fichiers de session
Un répertoire de sessions qui grossit anormalement trahit presque toujours un problème de nettoyage : soit le mécanisme de garbage collection de PHP est mal configuré, soit un pic de trafic génère des sessions plus vite qu’elles ne peuvent être purgées. Un simple comptage donne déjà une bonne indication de l’ampleur du problème :
find /var/lib/php/sessions -type f -name 'sess_*' | wc -l
Les directives session.gc_probability, session.gc_divisor et session.gc_maxlifetime, définies dans php.ini ou dans la configuration du pool PHP-FPM, gouvernent la fréquence et le seuil d’âge de ce nettoyage automatique. Une valeur de gc_probability trop faible, combinée à un fort trafic, peut suffire à laisser s’accumuler des dizaines de milliers de fichiers obsolètes.
Nettoyer sans couper les visiteurs actifs
La tentation, face à un répertoire saturé, est de tout supprimer d’un coup avec un rm -rf. C’est précisément ce qu’il ne faut pas faire en pleine charge : cela déconnecterait instantanément tous les visiteurs ayant une session active, panier WooCommerce compris. Une purge sélective, basée sur l’âge des fichiers, est bien plus sûre :
find /var/lib/php/sessions -type f -name 'sess_*' -mmin +30 -delete
Cette commande supprime uniquement les fichiers de session inactifs depuis plus de trente minutes, une durée à adapter selon la valeur de session.gc_maxlifetime configurée sur le serveur. Les sessions des visiteurs réellement en train de naviguer, dont le fichier a été modifié récemment, restent intactes.
Vérifier les permissions et la propriété du répertoire
Un répertoire de sessions saturé peut aussi révéler un problème de permissions distinct de la saturation elle-même : si plusieurs pools PHP-FPM tournant sous des utilisateurs différents écrivent dans le même répertoire partagé, l’un peut se retrouver bloqué par les fichiers d’un autre. Isoler un répertoire de sessions par site, avec un chemin défini dans session.save_path propre à chaque pool, évite ce type de contamination croisée.
- Vérifier l’espace disque disponible avec
df -h - Vérifier le quota d’inodes disponible avec
df -i - Compter les fichiers de session accumulés
- Purger sélectivement par ancienneté, jamais en bloc
- Contrôler les directives de garbage collection dans la configuration PHP
Prévenir la récidive
Une fois l’incident résolu, il reste à comprendre pourquoi le mécanisme automatique de PHP n’a pas suffi. Un pic de trafic inhabituel, une extension qui crée des sessions pour des visiteurs anonymes qui n’en ont pas réellement besoin, ou un gc_maxlifetime réglé trop haut pour le volume du site sont les explications les plus courantes.
Sur nos serveurs, nous surveillons désormais le nombre de fichiers dans les répertoires de sessions au même titre que l’espace disque : c’est un signal d’alerte précoce, souvent visible bien avant que le disque ne soit réellement plein.
En résumé
Le warning « session_start(): open(…) failed » recouvre deux causes distinctes, disque plein ou quota d’inodes atteint, qu’il faut distinguer avant d’agir. Une purge sélective par ancienneté, plutôt qu’une suppression globale, permet de résorber la saturation sans déconnecter les visiteurs dont la session est encore active.
