Expire Anonymous user sessions
kbahey - July 9, 2006 - 05:38
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | user system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | kbahey |
| Status: | patch (code needs review) |
Description
Is anyone else bothered by thousands of rows in the sessions table?
Here is a patch that uses cron to expire session entries for anonymous users. This only happens once a day so as not to load the database unnecessarily, and the expiry period is configurable.
| Attachment | Size |
|---|---|
| session-expire.patch.txt | 1.41 KB |
#1
Ehm, this is a "won't fix". PHP is responsible for this. You can configure the session lifetime in setting.php. PHP's garbage collector will then periodically call Drupal's sess_gc() function with the proper argument.
#2
In my case, it is set to 1440 (Debian default in php.ini), but it never had any effect.
Are you sure sess_gc() gets called on Drupal.org?
Could it be because the default in php.ini for save_handler is set to files and not user, and overridden in .htaccess?
Anyone has this working at all the way it should?
Also note that my patch limits what it does to anonymous sessions, not all sessions like what is in sess_gc().
#3
chheck your settings.php- that's probably superceeding the setting you have in php.ini.
At the least, I know that changing session cookie lifeting in settings.php does afffect how sessions are handled.
#4
This is standard drupal stuff that I did not change.
Here is how php is setup:
$ grep lifetime /etc/xxx/php.inisession.cookie_lifetime = 0
; /etc/cron.d/php5, which uses the session.gc_maxlifetime setting below
session.gc_maxlifetime = 1440
Here is how Drupal is setup:
$ grep lifetime xxx/.htaccess
$ grep lifetime sites/xxx/settings.php
ini_set('session.cookie_lifetime', 2000000);
ini_set('session.gc_maxlifetime', 200000);
The cron stuff is standard Debian fare.
$ cat /etc/cron.d/php5
# Look for and purge old sessions every 30 minutes
09,39 * * * * root [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm
$ cat /usr/lib/php5/maxlifetime
#!/bin/sh -e
max=1440
for ini in /etc/php5/*/php.ini; do
cur=$(sed -n -e 's/^[[:space:]]*session.gc_maxlifetime[[:space:]]*=[[:space:]]*\([0-9]\+\).*$/\1/p' $ini 2>/dev/null || true);
[ -z "$cur" ] && cur=0
[ "$cur" -gt "$max" ] && max=$cur
done
echo $(($max/60))
exit 0
Nothing there handles non-file sessions ...
#5
Have you looked at your settings.php?
#6
Yes, and I listed what is in it:
$ grep lifetime sites/xxx/settings.phpini_set('session.cookie_lifetime', 2000000);
ini_set('session.gc_maxlifetime', 200000);
These are the standard settings that ship with Drupal, and still, no cleanup happens.
My question agains is: does it happen on Drupal.org? Anyone else having sess_gc() called automatically?
#7
In view of people complaining of us delegating session cleanup to PHP garbage collection, for example this issue, I like to revive this.
If it has a chance of getting in, let me know, I will reroll and test.
#8
If this isn't being handled properly, then it's a bug (or someone else should won't fix it again if it is). Either way it needs a re-roll.
#9
Well, to solve the problem at hand, I created a separate session expire module http://drupal.org/project/session_expire
It is more configurable than this patch can ever be.
#10
I can definitely confirm that sess_gc() never gets called. This is on a Debian Etch system with a standard PHP5 installation. The reason it doesn't work on Debian/Ubuntu is explained at http://drupal.org/node/160046 (which is marked as a duplicate of this issue).
As a start at fixing this, what about patching settings.php as suggested over two years ago (http://drupal.org/node/35834)?:
ini_set('session.gc_probability', 1);ini_set('session.gc_divisor', 100);
A patch for 6.x is attached. I can confirm that this works for me (note that for testing purposes you may want to set session.gc_probability to 100 so that garbage collection is triggered on all page loads rather than on 1% of them). I believe this will fix the problem for a very large chunk of Debian/Ubuntu users out there.
However, I agree with the original poster that the best way to solve this problem in the long run is to call the garbage collection from within cron... that way it's guaranteed to happen for everyone regardless of their PHP configuration....
#11
This is like the third time this has happened to me on Drupal. I know I attached the patch but it didn't get posted. Anyway....