Nettoyer les fichiers de session PHP obsolètes sous Debian et Ubuntu

Lorsque des milliers de fichiers sess_* occupent les inodes d’un serveur, vérifiez d’abord le service Debian phpsessionclean.timer. Il nettoie automatiquement les sessions PHP expirées selon leur chemin et leur durée de vie. Une suppression manuelle avec find ne doit intervenir qu’après avoir identifié le gestionnaire, le chemin et la valeur session.gc_maxlifetime réellement utilisés par PHP-FPM.

Les sessions PHP stockées sous forme de fichiers sont petites. Pourtant, un serveur peut en accumuler plusieurs centaines de milliers. Le volume occupé reste parfois modeste, mais chaque fichier consomme un inode.

Lorsque tous les inodes d’un système de fichiers sont utilisés, Linux ne peut plus créer de nouveaux fichiers. Le serveur renvoie alors l’erreur No space left on device, même si plusieurs gigaoctets restent disponibles.

Sous Debian et Ubuntu, le paquet php-common fournit normalement un script et un timer systemd chargés de nettoyer ces sessions. Avant d’ajouter une tâche cron personnelle, il faut donc vérifier pourquoi ce mécanisme ne fonctionne plus.

Comment PHP stocke-t-il les sessions ?

PHP peut enregistrer les sessions avec plusieurs gestionnaires. Le gestionnaire historique utilise des fichiers locaux :

session.save_handler = files

Le chemin de stockage est défini par :

session.save_path = /var/lib/php/sessionsLangage du code : JavaScript (javascript)

Chaque session produit alors un fichier portant généralement un nom semblable à :

sess_4efe62a42e47ca4a5e89e12197a7eaf4

Le fichier contient les données associées à l’identifiant de session envoyé au navigateur. Selon l’application, il peut mémoriser un panier, un formulaire, une authentification ou un état temporaire.

Les installations plus avancées peuvent utiliser Redis, Memcached, une base de données ou un gestionnaire personnalisé. Dans ce cas, aucun nettoyage de /var/lib/php/sessions ne réglera le stockage réellement utilisé.

Vérifier si les inodes sont réellement saturés

Commencez par contrôler l’espace disque classique :

df -hT

Vérifiez ensuite les inodes :

df -i

Une sortie problématique peut ressembler à ceci :

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/nvme0n1p2   655360  655340      20  100% /

Le disque n’est pas nécessairement plein en octets. Il ne reste simplement plus d’inodes pour créer un fichier, un socket, un cache ou un journal supplémentaire.

Compter les fichiers de session PHP

Sur une installation Debian classique, comptez les sessions avec :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -printf '.' |
wc -cLangage du code : JavaScript (javascript)

Cette variante n’affiche pas des centaines de milliers de noms dans le terminal. Elle imprime seulement un caractère par fichier, puis les compte.

Pour afficher l’espace disque apparent occupé par le répertoire :

sudo du -sh /var/lib/php/sessionsLangage du code : JavaScript (javascript)

Pour connaître le nombre total d’entrées, y compris les autres fichiers éventuels :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -printf '.' |
wc -cLangage du code : JavaScript (javascript)

Identifier les répertoires qui consomment le plus d’inodes

Lorsque l’origine du problème reste inconnue, recherchez les répertoires contenant le plus de fichiers dans le système de fichiers racine :

sudo find / -xdev -type f \
    -printf '%h\n' 2>/dev/null |
sort |
uniq -c |
sort -nr |
head -30Langage du code : JavaScript (javascript)

L’option -xdev empêche find de parcourir les autres systèmes de fichiers montés. Elle évite notamment de traverser un NAS, un volume de sauvegarde ou une partition indépendante.

Pour analyser uniquement /var :

sudo find /var -xdev -type f \
    -printf '%h\n' 2>/dev/null |
sort |
uniq -c |
sort -nr |
head -30Langage du code : JavaScript (javascript)

Cette analyse peut prendre du temps sur un serveur contenant plusieurs millions de fichiers. Lancez-la dans tmux lorsque la connexion SSH est instable.

Vérifier le gestionnaire et le chemin réellement utilisés

Ne partez pas du principe que toutes les sessions se trouvent dans /var/lib/php/sessions. Un pool PHP-FPM peut définir son propre chemin, tandis que le PHP CLI en utilise un autre.

Examiner les fichiers de configuration PHP

Recherchez les directives actives dans toutes les versions installées :

sudo grep -RHE \
    '^[[:space:]]*session\.(save_handler|save_path|gc_maxlifetime|gc_probability|gc_divisor)[[:space:]]*=' \
    /etc/php/*/*/php.ini \
    /etc/php/*/fpm/pool.d/*.conf \
    /etc/php/*/*/conf.d/*.ini \
    2>/dev/nullLangage du code : JavaScript (javascript)

Cette commande permet de repérer :

• plusieurs versions de PHP ;
• des valeurs différentes entre CLI, FPM et Apache ;
• un chemin personnalisé défini dans un pool ;
• une durée de vie modifiée ;
• un gestionnaire Redis ou Memcached.

Interroger un pool PHP-FPM

Le binaire CLI n’utilise pas nécessairement le même fichier php.ini que PHP-FPM. Pour obtenir les valeurs du contexte web, créez temporairement un fichier protégé dans le site :

<?php

declare(strict_types=1);

header('Content-Type: text/plain; charset=utf-8');

printf(
    "save_handler=%s\nsave_path=%s\ngc_maxlifetime=%s\ngc_probability=%s\ngc_divisor=%s\n",
    ini_get('session.save_handler'),
    session_save_path(),
    ini_get('session.gc_maxlifetime'),
    ini_get('session.gc_probability'),
    ini_get('session.gc_divisor')
);Langage du code : HTML, XML (xml)

Consultez le fichier localement, puis supprimez-le immédiatement. Même s’il révèle peu d’informations, un fichier de diagnostic ne doit pas rester publiquement accessible.

Sur un serveur administré, vous pouvez aussi interroger directement le service FPM avec un script FastCGI ou examiner la configuration calculée du pool. Dans la plupart des cas, la recherche dans /etc/php/ suffit à retrouver les surcharges.

Comprendre session.gc_maxlifetime

La directive session.gc_maxlifetime indique le nombre de secondes après lequel les données d’une session deviennent éligibles au nettoyage.

session.gc_maxlifetime = 1440

La valeur par défaut de 1 440 secondes correspond à 24 minutes. Elle ne garantit toutefois pas que le fichier sera supprimé précisément après 24 minutes.

Il faut distinguer plusieurs notions :

• session.gc_maxlifetime définit quand les données deviennent nettoyables ;
• session.cookie_lifetime contrôle la durée du cookie dans le navigateur ;
• session.gc_probability et session.gc_divisor contrôlent le déclenchement probabiliste du nettoyage par PHP ;
• une application peut définir ses propres valeurs à l’exécution ;
• un autre gestionnaire de sessions peut appliquer sa propre expiration.

Une valeur de cookie plus longue n’empêche pas PHP de supprimer les données côté serveur. Le navigateur peut alors conserver un identifiant dont les données n’existent plus.

Pourquoi Debian désactive-t-il souvent le nettoyage probabiliste ?

PHP peut lancer son ramasse-miettes pendant une requête web selon la probabilité suivante :

session.gc_probability / session.gc_divisor

Avec les valeurs 1 et 100, le nettoyage possède une probabilité de 1 % à chaque initialisation de session.

Cette méthode possède trois défauts :

• un site peu fréquenté peut conserver ses fichiers trop longtemps ;
• un site très fréquenté peut lancer trop souvent une opération coûteuse ;
• le visiteur dont la requête déclenche le nettoyage subit sa durée.

PHP recommande donc, en production, de fixer session.gc_probability à 0 et de déclencher périodiquement le nettoyage avec un ordonnanceur. Debian et Ubuntu suivent cette stratégie grâce à phpsessionclean.

Vérifier le timer phpsessionclean

Le paquet php-common fournit normalement les composants suivants :

/usr/lib/php/sessionclean
/usr/lib/systemd/system/phpsessionclean.service
/usr/lib/systemd/system/phpsessionclean.timer
/etc/cron.d/php

Systemd utilise le timer lorsque le système fonctionne avec systemd. Le fichier cron sert notamment de solution compatible avec d’autres environnements.

Vérifiez l’état du timer :

sudo systemctl status phpsessionclean.timer --no-pagerLangage du code : CSS (css)

Affichez la prochaine exécution :

systemctl list-timers \
    --all \
    phpsessionclean.timerLangage du code : CSS (css)

Le timer doit être chargé et actif. Sa fréquence exacte dépend de la version du paquet, mais le nettoyage doit se produire régulièrement, et non une seule fois par jour.

Réactiver phpsessionclean.timer

Lorsque le timer est désactivé, activez-le immédiatement :

sudo systemctl enable --now phpsessionclean.timerLangage du code : CSS (css)

Vérifiez ensuite son état :

sudo systemctl is-enabled phpsessionclean.timer
sudo systemctl is-active phpsessionclean.timerLangage du code : CSS (css)

Les résultats attendus sont :

enabled
active

Lancer immédiatement le nettoyage Debian

Pour exécuter le service sans attendre la prochaine échéance :

sudo systemctl start phpsessionclean.serviceLangage du code : CSS (css)

Vérifiez ensuite son résultat :

sudo systemctl status \
    phpsessionclean.service \
    --no-pagerLangage du code : CSS (css)

Un service de type oneshot peut apparaître comme inactive (dead) après une exécution réussie. Ce statut est normal : le processus s’arrête une fois le nettoyage terminé.

Consultez les journaux récents :

sudo journalctl \
    -u phpsessionclean.service \
    --since '24 hours ago' \
    --no-pagerLangage du code : JavaScript (javascript)

Comprendre ce que fait le script Debian

Le script Debian ne se contente pas d’exécuter une commande find avec une valeur fixe.

Il détermine notamment les chemins de sessions et les durées de vie configurées pour les différentes versions et interfaces PHP. Il protège également les fichiers encore ouverts par les processus PHP avant de supprimer les sessions trop anciennes.

Cette précaution compte avec session.lazy_write=1. Lorsque les données de la session n’ont pas changé, PHP peut éviter de réécrire le fichier. Sa date de modification ne reflète donc pas toujours la dernière requête du visiteur.

Le mécanisme fourni par la distribution reste ainsi préférable à une commande universelle de ce genre :

find /var/lib/php/sessions \
    -type f \
    -mmin +24 \
    -name 'sess_*' \
    -deleteLangage du code : JavaScript (javascript)

Cette commande peut être utile en urgence. Elle ne doit pas devenir la solution permanente sans vérifier les sessions actives, les durées de vie et les différents pools.

Diagnostiquer un échec de phpsessionclean

Si le service échoue, affichez son unité complète :

systemctl cat phpsessionclean.service
systemctl cat phpsessionclean.timerLangage du code : CSS (css)

Examinez ensuite les journaux détaillés :

sudo journalctl \
    -u phpsessionclean.service \
    -u phpsessionclean.timer \
    --since '7 days ago' \
    --no-pagerLangage du code : JavaScript (javascript)

Contrôlez également la présence et les droits du script :

sudo stat /usr/lib/php/sessionclean
sudo test -x /usr/lib/php/sessionclean && echo 'Script exécutable'Langage du code : PHP (php)

Vérifiez enfin le paquet qui fournit le fichier :

dpkg-query -S /usr/lib/php/sessionclean
dpkg-query -W php-common

Réinstaller php-common si le mécanisme est absent

Lorsque les fichiers du service manquent ou semblent endommagés, réinstallez le paquet :

sudo apt update
sudo apt install --reinstall php-common

Rechargez ensuite la configuration systemd :

sudo systemctl daemon-reload
sudo systemctl enable --now phpsessionclean.timerLangage du code : CSS (css)

Lancez un test immédiat :

sudo systemctl start phpsessionclean.service

sudo journalctl \
    -u phpsessionclean.service \
    -n 50 \
    --no-pagerLangage du code : CSS (css)

Nettoyer manuellement les sessions en cas d’urgence

Lorsque les inodes atteignent 100 %, certains services ne peuvent plus écrire leurs journaux ou créer leurs fichiers temporaires. Il peut devenir nécessaire de libérer rapidement quelques milliers d’inodes avant de réparer le mécanisme automatique.

Commencez par afficher les sessions âgées de plus d’une heure sans les supprimer :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -mmin +60 \
    -print |
head -100Langage du code : PHP (php)

Comptez-les :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -mmin +60 \
    -printf '.' |
wc -cLangage du code : JavaScript (javascript)

Lorsque vous avez confirmé le chemin et accepté de déconnecter les sessions concernées, supprimez-les avec :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -mmin +60 \
    -deleteLangage du code : JavaScript (javascript)

-delete évite le tube vers xargs. La commande ne traite que les fichiers réguliers nommés sess_* directement présents dans le répertoire.

La durée d’une heure n’est qu’un exemple prudent pour une intervention d’urgence. Utilisez la valeur réellement configurée lorsque vous la connaissez.

Pourquoi utiliser -mmin plutôt que -cmin ?

Les deux critères ne mesurent pas la création du fichier :

• -mmin utilise la date de dernière modification du contenu ;
• -cmin utilise la date du dernier changement des métadonnées de l’inode.

Un changement de propriétaire, de permissions ou de lien modifie le ctime. Pour une session stockée dans un fichier, le mtime représente généralement mieux la dernière écriture des données.

Cela ne rend pas la suppression parfaite pour autant. Avec l’écriture paresseuse de PHP, une session consultée sans modification peut conserver un ancien mtime. C’est une raison supplémentaire de préférer le script de la distribution.

Ne pas supprimer toutes les sessions sans nécessité

La commande suivante est trop brutale pour un serveur en production :

sudo rm -f /var/lib/php/sessions/sess_*Langage du code : JavaScript (javascript)

Elle supprime également les sessions actives. Les utilisateurs peuvent être déconnectés, perdre un panier ou devoir recommencer un formulaire.

Une suppression complète peut néanmoins se justifier dans quelques situations :

• incident de sécurité nécessitant l’invalidation de toutes les sessions ;
• site placé en maintenance sans utilisateur actif ;
• environnement de développement ou de préproduction ;
• répertoire entièrement orphelin d’une ancienne version PHP.

Dans ce dernier cas, vérifiez d’abord qu’aucun processus ne conserve un fichier ouvert :

sudo lsof +D /var/lib/php/sessions 2>/dev/null |
head -100Langage du code : JavaScript (javascript)

Sur un répertoire gigantesque, lsof +D peut être coûteux. Utilisez-le avec mesure.

Vérifier les résultats après le nettoyage

Recomptez les sessions :

sudo find /var/lib/php/sessions \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -printf '.' |
wc -cLangage du code : JavaScript (javascript)

Contrôlez les inodes :

df -i

Puis vérifiez les services qui avaient échoué faute d’espace :

systemctl --failed
journalctl --priority=err --since '1 hour ago'Langage du code : JavaScript (javascript)

Il peut être nécessaire de redémarrer ou de recharger un service qui n’a pas pu créer son socket, son PID ou son fichier temporaire. Ne redémarrez toutefois pas tout le serveur par réflexe.

Cas particulier : plusieurs versions de PHP

Un serveur peut exécuter simultanément PHP 8.2, PHP 8.4 et PHP 8.5. Chaque version possède ses propres fichiers de configuration :

/etc/php/8.2/fpm/php.ini
/etc/php/8.4/fpm/php.ini
/etc/php/8.5/fpm/php.ini

Les pools peuvent partager le même répertoire de sessions ou utiliser des chemins séparés.

Listez les versions installées :

find /etc/php \
    -mindepth 1 \
    -maxdepth 1 \
    -type d \
    -printf '%f\n' |
sort -VLangage du code : JavaScript (javascript)

Listez les services FPM :

systemctl list-units \
    --type=service \
    'php*-fpm.service'Langage du code : PHP (php)

Lorsque plusieurs configurations partagent le même session.save_path, la durée la plus courte peut provoquer la suppression des sessions attendues plus longtemps par une autre application. PHP recommande d’associer les durées différentes à des chemins distincts.

Cas particulier : un chemin de session personnalisé

Un pool peut isoler les sessions d’un site dans un répertoire dédié :

php_admin_value[session.save_path] = /var/lib/php/sessions/exampleLangage du code : JavaScript (javascript)

Créez le répertoire avec des permissions strictes :

sudo install \
    --directory \
    --owner=example \
    --group=example \
    --mode=0700 \
    /var/lib/php/sessions/exampleLangage du code : JavaScript (javascript)

Le propriétaire doit correspondre à l’utilisateur du pool PHP-FPM. Un répertoire partagé et lisible par tous les utilisateurs du serveur augmente le risque d’exposition des sessions.

Après la modification du pool, validez et rechargez PHP-FPM :

sudo php-fpm8.5 -t
sudo systemctl reload php8.5-fpm.serviceLangage du code : CSS (css)

Adaptez évidemment la version de PHP au serveur.

Créer un timer systemd pour un chemin non pris en charge

Le mécanisme Debian doit rester le premier choix. Cependant, un gestionnaire personnalisé, un conteneur ou une configuration atypique peut nécessiter son propre nettoyage.

Dans ce cas, créez un service spécifique plutôt qu’un cron quotidien.

Créer le script

sudo nano /usr/local/sbin/cleanup-example-php-sessions

Ajoutez :

#!/usr/bin/env bash

set -Eeuo pipefail

readonly session_path='/var/lib/php/sessions/example'
readonly max_lifetime_minutes='60'

if [[ ! -d "${session_path}" ]]; then
    printf 'Répertoire absent : %s\n' "${session_path}" >&2
    exit 0
fi

find "${session_path}" \
    -xdev \
    -maxdepth 1 \
    -type f \
    -name 'sess_*' \
    -mmin "+${max_lifetime_minutes}" \
    -deleteLangage du code : PHP (php)

Rendez-le exécutable :

sudo chmod 0750 \
    /usr/local/sbin/cleanup-example-php-sessions

Le chemin et la durée sont explicites. Le script ne tente pas de déduire les paramètres avec le PHP CLI, dont la configuration pourrait être différente.

Créer le service systemd

sudo nano \
    /etc/systemd/system/cleanup-example-php-sessions.service

Ajoutez :

[Unit]
Description=Nettoyage des sessions PHP expirées du pool example
Documentation=man:find(1)

[Service]
Type=oneshot
User=example
Group=example
ExecStart=/usr/local/sbin/cleanup-example-php-sessions

NoNewPrivileges=true
PrivateDevices=true
PrivateTmp=true
ProtectClock=true
ProtectControlGroups=true
ProtectHome=true
ProtectHostname=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectSystem=strict
ReadWritePaths=/var/lib/php/sessions/example
RestrictAddressFamilies=AF_UNIX
RestrictNamespaces=trueLangage du code : JavaScript (javascript)

Le service s’exécute avec l’utilisateur du pool. Il ne possède un accès en écriture qu’au répertoire de sessions concerné.

Créer le timer

sudo nano \
    /etc/systemd/system/cleanup-example-php-sessions.timer

Ajoutez :

[Unit]
Description=Planification du nettoyage des sessions PHP du pool example

[Timer]
OnBootSec=15min
OnUnitActiveSec=30min
AccuracySec=5min
Persistent=true
Unit=cleanup-example-php-sessions.service

[Install]
WantedBy=timers.targetLangage du code : JavaScript (javascript)

Rechargez systemd et activez le timer :

sudo systemctl daemon-reload

sudo systemctl enable --now \
    cleanup-example-php-sessions.timerLangage du code : CSS (css)

Testez le service :

sudo systemctl start \
    cleanup-example-php-sessions.service

sudo journalctl \
    -u cleanup-example-php-sessions.service \
    -n 50 \
    --no-pagerLangage du code : CSS (css)

Vérifiez la prochaine exécution :

systemctl list-timers \
    cleanup-example-php-sessions.timerLangage du code : CSS (css)

Ce timer reste moins sophistiqué que le script Debian. Il convient surtout à un chemin isolé dont vous maîtrisez la durée de vie et l’utilisateur.

Utiliser session_gc() avec un ordonnanceur

Depuis PHP 7.1, la fonction session_gc() permet de déclencher explicitement le ramasse-miettes du gestionnaire de sessions.

Un script minimal peut ressembler à ceci :

<?php

declare(strict_types=1);

ini_set('session.save_handler', 'files');
ini_set('session.save_path', '/var/lib/php/sessions/example');
ini_set('session.gc_maxlifetime', '3600');

session_start();

$deleted = session_gc();

session_destroy();

if (false === $deleted) {
    fwrite(STDERR, "Le nettoyage des sessions a échoué.\n");
    exit(1);
}

printf("Entrées supprimées : %d\n", $deleted);Langage du code : HTML, XML (xml)

Le script doit utiliser exactement le même gestionnaire, le même chemin et les mêmes permissions que l’application web. Il doit aussi s’exécuter avec un utilisateur autorisé à lire et supprimer les sessions.

Pour un stockage par fichiers classique sous Debian, phpsessionclean reste généralement plus simple et mieux intégré. session_gc() devient surtout utile avec une application ou un gestionnaire personnalisé.

Sessions stockées dans Redis ou Memcached

Si la configuration indique :

session.save_handler = redis

ou :

session.save_handler = memcached

les sessions ne sont pas gérées par des fichiers sess_*. Leur expiration dépend du gestionnaire et de sa configuration.

Dans Redis, examinez notamment l’URL configurée, le préfixe des clés et leur TTL. N’utilisez pas une commande globale telle que FLUSHDB sur une instance partagée avec le cache objet WordPress, les files de tâches ou d’autres applications.

Le bon diagnostic consiste donc toujours à commencer par session.save_handler. Nettoyer le mauvais stockage produit un résultat techniquement impeccable et parfaitement inutile.

Sécuriser le répertoire des sessions

Les fichiers de session contiennent parfois des données sensibles. Le répertoire ne doit pas être publiquement lisible.

Vérifiez ses permissions :

sudo stat /var/lib/php/sessions
sudo namei -l /var/lib/php/sessionsLangage du code : JavaScript (javascript)

Sur Debian, le répertoire partagé peut utiliser le sticky bit afin que plusieurs utilisateurs PHP puissent créer leurs fichiers sans supprimer ceux des autres. Ne remplacez pas ses permissions par un 0777 générique.

Pour des pools PHP-FPM isolés, un répertoire propre à chaque utilisateur avec le mode 0700 offre une séparation plus nette.

Surveiller les inodes avant la prochaine panne

Le nettoyage corrige le symptôme immédiat. Une supervision évite de découvrir le problème lorsque WordPress ne peut déjà plus écrire un fichier.

Une vérification simple peut afficher les systèmes de fichiers dépassant 80 % d’utilisation des inodes :

df -Pi |
awk '
    NR > 1 {
        usage = $5;
        gsub("%", "", usage);

        if (usage >= 80) {
            printf "%s : %s%% des inodes utilisés sur %s\n",
                $1,
                usage,
                $6;
        }
    }
'Langage du code : PHP (php)

Dans un environnement de production, intégrez cette métrique à votre outil de supervision. Déclenchez une alerte avant 90 %, car les derniers inodes peuvent disparaître très vite lorsqu’un processus boucle.

Checklist de diagnostic

• vérifier l’espace avec df -hT ;
• vérifier les inodes avec df -i ;
• identifier les répertoires contenant le plus de fichiers ;
• contrôler session.save_handler ;
• retrouver le session.save_path du contexte PHP-FPM ;
• vérifier la valeur réelle de session.gc_maxlifetime ;
• contrôler les différentes versions et les différents pools PHP ;
• vérifier phpsessionclean.timer ;
• examiner les journaux du service ;
• lancer le nettoyage Debian manuellement ;
• ne supprimer manuellement que les sessions réellement expirées ;
• recontrôler les inodes et les services en échec ;
• ajouter une alerte de supervision.

Conclusion

La meilleure correction n’est plus d’ajouter aveuglément une ligne à la crontab. Sous Debian et Ubuntu, commencez par réparer phpsessionclean.timer et vérifier les paramètres réellement utilisés par PHP-FPM.

Une commande find reste utile pour libérer des inodes en urgence ou gérer un répertoire personnalisé. Elle doit toutefois cibler le bon chemin, respecter la durée de vie des sessions et éviter de supprimer les connexions encore actives.

Enfin, surveillez les inodes comme l’espace disque. Un serveur peut disposer de 100 Go libres et se retrouver tout de même incapable de créer un fichier. Linux aime rappeler que « de la place » possède plusieurs définitions.

Questions fréquentes

Peut-on supprimer tous les fichiers sess_* sans risque ?

Non. Les fichiers peuvent appartenir à des sessions encore actives. Leur suppression déconnecte les utilisateurs et peut effacer des paniers ou des données temporaires. Il faut cibler les sessions expirées ou intervenir pendant une maintenance contrôlée.

Pourquoi utiliser phpsessionclean plutôt qu’une tâche cron personnelle ?

Le script Debian tient compte des configurations PHP installées, des durées de vie et des sessions ouvertes. Une tâche cron générique fondée sur le PHP CLI peut utiliser un mauvais chemin ou supprimer des sessions encore nécessaires.

Que signifie session.gc_maxlifetime ?

Cette directive définit le nombre de secondes après lequel une session devient éligible au nettoyage. Elle ne garantit pas une suppression exactement à cette échéance et ne correspond pas forcément à la durée du cookie du navigateur.

Pourquoi PHP conserve-t-il des sessions pendant plusieurs jours ?

Le timer de nettoyage peut être désactivé ou en échec. Le chemin peut aussi être personnalisé, la durée de vie augmentée ou le répertoire ignoré par le mécanisme de la distribution.

Pourquoi df indique-t-il de l’espace libre malgré No space left on device ?

Le système de fichiers peut manquer d’inodes plutôt que d’octets. Vérifiez les deux ressources avec df -hT et df -i.

Le nettoyage concerne-t-il les sessions Redis ?

Non. Les commandes visant /var/lib/php/sessions concernent uniquement le gestionnaire files. Redis, Memcached et les gestionnaires personnalisés possèdent leurs propres mécanismes d’expiration.

Articles complémentaires

• Résoudre l’erreur « No space left on device » causée par les inodes
• Configurer Apache avec PHP-FPM et MPM Event
• Installer Nginx, PHP et MariaDB sous Debian

Sources

• Manuel PHP : configuration des sessions
• Manuel PHP : fonction session_gc()
• Debian : fichiers fournis par le paquet php-common
• Manuel Linux : commande find
• Documentation systemd : unités timer

Report a typo