Debian and derivatives (Ubuntu) don't use the php session garbage collector

session.gc_probability = 0

instead they use a cron /etc/cron.d/php5

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

Why Debian has chosen to do this?

2 Answers 2


Because Debian sets very stringent permissions on /var/lib/php5 (1733, owner root, group root) to prevent PHP session hijacking. Unfortunately, this also prevents the native PHP session garbage collector from working, because it can't see the session files there. The cron job runs as root, which does have sufficient access to see and clean up the session files.

Edit: Supporting documentation: The behavior was established in response to bug #267720. (There used to be comments in the stock php.ini file about this, but I don't see them there now in my wheezy-based PHP install.)

  • Perms on /var/lib/php5 ar drwx-wx-wt (rooot-root), so apache user can write the dir contents (sticky bit), but can't read it. So I understand that php's garbage collector won't be able to evalutate the atime of the session files so it can't choose which files to be deleted... am i right?
    – nulll
    Commented May 30, 2013 at 7:31
  • Yes, that's correct.
    – asciiphil
    Commented May 30, 2013 at 12:39

It's likely to be a bit more reliable on sites with low traffic (if you only get a couple hundred hits a day and GC only fires every thousand or so, sessions might stick around way longer than they should) and I imagine it might be a little less harsh on the server than the native GC if you've got lots of sessions.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .