PHP-Sitzungsdaten werden bei Verwendung von benutzerdefinierter Sitzungsverwaltung auf Debian (und Ubuntu) nicht gelöscht

Auf Debian-Systemen (soweit ich weiß, gilt dies auch für Ubuntu) ist der Garbage Collector für PHP-Sitzungen standardmäßig deaktiviert.

Die entsprechende Einstellung in php.ini ist session.gc_probability = 0, die den Garbage Collector aktiviert, wenn sie auf einen Wert größer als null gesetzt wird. Der Standardwert in PHP ist 1, sodass der Garbage Collector bei jedem PHP-Skriptaufruf mit einer Wahrscheinlichkeit von 1/100 aufgerufen wird.

Auf Debian-Systemen ist diese Einstellung deaktiviert, weil der Standardpfad für die Sitzungsablage nicht beschreibbar für den Webserver-Prozess ist (und das sollte er auch nicht sein). Das Löschen von veralteten Sitzungsdateien erfolgt hier durch einen System-Cron-Job.

Nachfolgend ein Auszug aus der php.ini:

; Dies ist in den Debian-Paketen deaktiviert, aufgrund der strengen Berechtigungen
; auf /var/lib/php5.  Anstatt dies hier einzustellen, siehe den Cronjob unter
; /etc/cron.d/php5, der die Einstellung session.gc_maxlifetime unten verwendet.
; PHP-Skripte, die ihren eigenen session.save_path verwenden, sollten sicherstellen,
; dass die Garbage Collection aktiviert ist, indem sie session.gc_probability setzen
;session.gc_probability = 0

Da diese Einstellung für Skripte, die die standardmäßige PHP-Sitzungsverwaltung (Datei) verwenden, in Ordnung ist, kann dies zu Problemen führen, wenn Sie Ihre eigene Sitzungsverwaltung verwenden, die ihre eigenen Routinen für das Lesen und Schreiben von Sitzungen mit session_save_handler() definiert. Diese Sitzungsverwaltungs-Klassen bieten in den meisten Fällen auch eine eigene Funktion für den Garbage Collector an.

Das Problem ist, dass diese Garbage Collector-Funktion auf einem Debian-System mit der oben genannten php.ini-Einstellung niemals aufgerufen wird. Dies ist entscheidend, wenn Sitzungsdaten in einer MySQL-Datenbank vom Typ MEMORY gespeichert werden. Diese Tabelle ist in der Größe durch den MySQL-Konfigurationswert max_heap_table_size begrenzt. Wenn diese Größe erreicht ist, schlägt das weitere Schreiben von Sitzungen fehl und damit wahrscheinlich auch die Website, die nicht mehr richtig funktioniert.

In Anbetracht dessen ist es wirklich wichtig, die php.ini-Einstellung für die Garbage Collection in Ihrer eigenen Sitzungsverwaltungs-Klasse zu überschreiben. Ich werde dies mit einem kleinen Beispiel einer Sitzungsverwaltungs-Klasse (ohne echtes Schreiben/Lesen) zeigen:

class session {
    function __destruct() {
        session_write_close();
    }
    function __construct() {
        @ini_set("session.use_trans_sid","0");
        @ini_set('session.gc_probability', 1); // in Debian ist dies standardmäßig deaktiviert...
         
        // benutzerdefinierte Sitzungshandler-Funktionen aktivieren
        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();
    }
 
    // benutzerdefinierte Sitzungshandler-Funktionen deklarieren
    function _sess_open($sSavePath, $sSessionName) {
        return true;
    }
     
    function _sess_close() {
        return true;
    }
     
    function _sess_read($sKey) {
        // Wert lesen und zurückgeben
    }
     
    function _sess_write($sKey, $val) {
        // neuen Wert schreiben
    }
     
    function _sess_destroy($sKey) {
        // Sitzung zerstören
    }
     
    function _sess_gc($iMaxLifeTime) {
        // alte Sitzungen löschen (aus der DB)
    } 
}
 
$mySession = new session();

Das Wichtige ist der Aufruf von @ini_set(‘session.gc_probability’, 1) innerhalb des Konstruktors. Danach sollte die Sitzungs-Garbage-Collection wie erwartet funktionieren, selbst auf Debian-Systemen mit Ihrer eigenen Sitzungsverwaltungs-Klasse.