PHP Sessions · 2 min read · Dec 27, 2025
Les données de session PHP ne sont pas supprimées lors de l'utilisation d'une gestion de session personnalisée sur debian (et ubuntu)
Sur les systèmes debian (autant que je sache, cela s’applique aussi à ubuntu), le ramasse-miettes pour les sessions PHP est désactivé par défaut.
Le paramètre correspondant dans php.ini est session.gc_probability = 0 qui active le ramasse-miettes lorsqu’il est défini à une valeur supérieure à zéro. La valeur par défaut dans PHP est 1, donc le ramasse-miettes est appelé avec une probabilité de 1/100 à chaque appel de script PHP.
Sur les systèmes debian, ce paramètre est désactivé en raison du fait que le chemin par défaut pour le stockage des sessions n’est pas accessible en écriture pour le processus du serveur web (et il ne devrait pas l’être non plus). La suppression des fichiers de session obsolètes est effectuée par un cron job système ici.
Voici un extrait du php.ini :
; Ceci est désactivé dans les paquets Debian, en raison des permissions strictes
; sur /var/lib/php5. Au lieu de le définir ici, voir le cronjob à
; /etc/cron.d/php5, qui utilise le paramètre session.gc_maxlifetime ci-dessous.
; Les scripts php utilisant leur propre session.save_path doivent s'assurer que le ramasse-miettes
; est activé en définissant session.gc_probability
;session.gc_probability = 0Comme ce paramètre est correct pour les scripts utilisant la gestion de session PHP par défaut (fichier), cela peut entraîner des problèmes lorsque vous utilisez votre propre gestion de session qui définit ses propres routines pour la lecture et l’écriture de session en utilisant session_save_handler(). Ces classes de gestion de session fourniront également une fonction propre pour le ramasse-miettes, dans la plupart des cas.
Le problème est que cette fonction de ramasse-miettes ne sera jamais appelée sur un système debian avec le paramètre php.ini mentionné ci-dessus. Cela est crucial lorsque les données de session sont stockées dans une base de données MySQL de type MEMORY. Cette table est limitée en taille par la valeur de configuration MySQL max_heap_table_size. Si cette taille est atteinte, toutes les écritures de session ultérieures échoueront et, avec elles, le site web risque de ne pas fonctionner correctement.
Sachant cela, il est vraiment important de remplacer le paramètre php.ini pour la collecte des ordures dans votre propre classe de gestion de session. Je vais montrer cela avec un petit exemple d’une classe de gestion de session (sans écriture/lecture réelle) :
class session {
function __destruct() {
session_write_close();
}
function __construct() {
@ini_set("session.use_trans_sid","0");
@ini_set('session.gc_probability', 1); // sur debian, cela est désactivé par défaut...
// activer les fonctions de gestionnaire de session personnalisées
session_set_save_handler(array(&$this,"_sess_open"),
array(&$this,"_sess_close"),
array(&$this,"_sess_read"),
array(&$this,"_sess_write"),
array(&$this,"_sess_destroy"),
array(&$this,"_sess_gc"));
@session_start();
}
// déclarer les fonctions de gestionnaire de session définies par l'utilisateur
function _sess_open($sSavePath, $sSessionName) {
return true;
}
function _sess_close() {
return true;
}
function _sess_read($sKey) {
// lire et retourner la valeur
}
function _sess_write($sKey, $val) {
// écrire une nouvelle valeur
}
function _sess_destroy($sKey) {
// détruire la session
}
function _sess_gc($iMaxLifeTime) {
// supprimer les anciennes sessions (de la db)
}
}
$mySession = new session();La chose importante est l’appel de @ini_set(‘session.gc_probability’, 1) à l’intérieur du constructeur. Après cela, la collecte des ordures de session devrait fonctionner comme prévu, même sur les systèmes debian avec votre propre classe de gestion de session.
Recevez de nouveaux articles dans votre boîte de réception.
Aucun spam. Désabonnez-vous à tout moment.