# « session_start(): open(…) failed » : diagnostiquer un espace de stockage de session saturé > Face à ce warning en pleine charge, une méthode pour repérer un répertoire de sessions PHP plein et le nettoyer sans déconnecter les visiteurs actifs. - Auteur : WordPress Développement - Publié le : 2020-12-12 - Mis à jour le : 2020-12-12 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/session-start-open-failed-stockage-sessions-sature/ ## L’essentiel - Le warning signale un répertoire de sessions inaccessible en écriture - inode et espace disque doivent être vérifiés séparément - Un nettoyage sélectif évite de couper les sessions actives « 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. > L'essentiel à retenir : Le warning signale un répertoire de sessions inaccessible en écriture ; inode et espace disque doivent être vérifiés séparément ; Un nettoyage sélectif évite de couper les sessions actives ## 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.