PHP Session Garbage Collection in anderen Verzeichnissen unter Ubuntu und Debian

von Nico Puhlmann

Eben entdeckt: Bei Ubuntu und Debian ist in PHP standardmässig die Garbage Collection deaktiviert. Diese sorgt dafür, das die Sessionfiles für abgelaufene Sessions automatisiert gelöscht werden. Bei Ubuntu und Debian löst ein Cronjob diesen Löschvorgang.

Ein Problem entsteht allerdings, wenn man eigene Verzeichnisse für die Sessionfiles definiert. Hier werden die Files dann nicht gelöscht und bleiben bestehen, was das Verzeichnis – je nach Traffic – schnell auf ein paar Tausende Dateien anwachsen lassen kann.

Um die Garbage Collection in PHP zu aktivieren, muss folgender Eintrag in der php.ini (für Apache unter /etc/php5/apache2/php.ini) geändert werden:

VORHER

;session.gc_probability = 0
session.gc_divisor = 100

NACHHER

session.gc_probability = 1
session.gc_divisor = 100

Diese Änderung bewirkt, das bei jedem hundertsten Start einer Session die Sessionfiles gelöscht werden.

Zusätzlich muss dann noch der Cronjob deaktiviert werden. Hierzu einfach /etc/cron.d/php5 mit dem Editor deiner Wahl bearbeiten und die letzte Zeile auskommentieren:

# /etc/cron.d/php5: crontab fragment for php5
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime

# Look for and purge old sessions every 30 minutes
#09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm

Was der Grund für diese Deaktivierung bei Ubuntu oder Debian war konnte ich auf die Schnelle nicht herausfinden, werde es aber in einem Update nachliefern.

Wenn in Linux-Distributionen solche Änderungen vorgenommen werden, sollte man aber passende Toolsets liefern, um alle Variationen abzufangen. So ist das nur eine halbe Sache, wenn ich nichts übersehen habe. Der Bug wurde auch schon im Ubuntu-Bugtracker aufgenommen, aber noch keinem zugeordnet.

Weiterführende Links:

Dir gefällt dieser Beitrag?
Erhalte Updates. Kostenlos.

3 Kommentare

  • Das ist weil Debian ziemlich strenge Rechte setzt auf /var/lib/php5 (1733, owner root, group root) um Sessions vor hijacking PHP zu schützen. Leider hindert das den PHP session garbage collector an der Arbeit, weil dieser die Files so nicht löschen werden können. Deshalb der Cron-Job welcher als root läuft.
    Antworten

  • Wenn ein fcgi-Server mit eigenen Verzeichnissen für die Sessions installiert wurde, befinden sich die Sessions nicht mehr unter /var/lib/php5.

    Ich bekomme dann folgende Fehlermeldung mit dieser Vorgehensweise:

    ( ! ) Fatal error: Uncaught exception 'Zend_Session_Exception' with message 'Zend_Session::start() - /var/www/sitename/www/webapp/library/Zend/Session.php(Line:480): Error #8 session_start() [function.session-start]: ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13) Array' in /var/www/sitename/www/webapp/library/Zend/Session.php on line 493

    ( ! ) Zend_Session_Exception: Zend_Session::start() - /var/www/twahoogle/www/webapp/library/Zend/Session.php(Line:480): Error #8 session_start() [function.session-start]: ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13) Array in /var/www/sitename/www/webapp/library/Zend/Session.php on line 493

    Deshalb habe ich für die Sessionpfade in den einzelnen vhosts wieder den Cron-Job aktiviert und lass den jetzt alle 15 Minuten unter root laufen.
    Antworten

  • Mannomannomann,
    was hab ich rumgekramt auf der Suche nach verschollenen Sessions. Danke für den Hinweis auf diese Debian-Spezialität. Und auf die Begründung, warum die das so machen, bin ich jetzt schon gespannt ...
    Gruss,
    Uli
    Antworten

Was denkst du?