The issue reported last year was dropped because folk were unable to replicate it, and called it misconfiguration.
However it's a very real problem, that I've now encountered on both Debian Etch and Ubuntu.

It's documented right out there in the distributed php.ini and on the PHP Website

I found myself fighting with all sorts of optimizations trying to combat :

2GB in the sessions table

... and going up all the time.

sess_gc() never, ever, gets triggered on a Debian system

No matter what gc_maxlifetime is set to.
Old sessions never die. I actually thought it was cute that I could come back to my dev sites weeks later and it'd recognise me, but not when our released site got over 100,000 anonymous users in a week. (plus, the application saves a couple of KB of serialized data in the session too)

Simply : Debian only clears dead session data if you are using the default 'files' method.

... if you write your own session handlers you'll need to explicitly call your _gc function yourself

So, I'm currently trying the solution from which triggers garbage collection on sess_close. I'm imagining that a better fix would be a cron hook for session

This was also accurately identified (but not fixed even earlier).

I am really happy that I've finally located our issue, and that performance is once again performing - after spending absolute days benchmarking and optimising and going slightly mad. This is apparently a debian only issue, but I need a suggestion on the very best way to work around it.

; This is disabled in the Debian packages, due to the strict permissions
; on /var/lib/php5.  Instead of setting this here, see the cronjob at
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below
;session.gc_probability = 0
session.gc_divisor     = 100

; After this number of seconds, stored data will be seen as 'garbage' and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440


- On a Current Debian system [Linux version 2.6.15-28-386 (Ubuntu 4.0.3-1ubuntu5)| Apache/2.0.55 (Ubuntu) PHP/5.1.2]
- Place a debug notice in function sess_gc()

watchdog('session','session garbage collection actually happened!');

- Set session.gc_maxlifetime to anything, in settings.conf which should over-ride php.ini.

   print t('Inactive user sessions will be dropped after %duration ',
      array('%duration' => ini_get("session.gc_maxlifetime"). ' seconds, or ' . format_interval( ini_get("session.gc_maxlifetime") ) )

- Start multiple sessions, anon sessions, clear cookies
- Wait that long. wait longer.
- Run cron, Run a spider, log in, log out, clear db cache, anything to bump it along!
- Search logs. No message
- View timestamps still in sessions table

SELECT count(*) FROM sessions;
SELECT uid, hostname, DATE_FORMAT(FROM_UNIXTIME(timestamp), '%D %M  %h:%i:%s ') as time, cache FROM sessions ORDER BY timestamp ;

Old dates there.

... old sessions are never dropped.


kbahey’s picture

I too am bothered by the fact that we delegate this to PHP, which is unpredictable.

I too, use Ubuntu.

In /etc/php5/apache2/php.ini, you will find this commented out:

;session.gc_probability = 0

If you set that to 1, it will probably do the trick, but when you upgrade, you have to remember to redo the chanage.

Regardless, I think leaving sessions around, specially for anonymous is too risky, given all the possible configurations out there.

I proposed a fix for this, whereby we use our predictable cron, and control it ourselves. You can see it in #72856, but it was rejected.

I could reroll the patch again, if it has a chance of being accepted.

Otherwise I will create a contrib module (or maybe a mini module) that just does that.

catch’s picture

Status: Active » Closed (duplicate)
Samat Jain’s picture

Debian reports this "fixed;" Debian's php.ini now includes a better warning. See Debian bug 388808.

With Debian's fix, Drupal still needs to handle this.