CI_Sessions table not cleaned up automatically

In my database, the ci_sessions table is growing bigger and bigger. Why is that? My site has a logout mechanism which destroys the session, but the record in the table is not being deleted.
Something wrong with my configuration? Or do I have to clean up the table myself?

Let me check the code I believe there is a garbage collector which follows the setting in the PHP.ini file (unless you changed that).

Give me a second...

https://github.com/ProjectOrangeBox / https://github.com/dmyers2004

In /Session/Session.php on line 117 array($class, 'gc') you can see they setup the garage collector.

I'm pretty sure this simply follows php's php.ini

session.gc_probability
session.gc_divisor
session.gc_maxlifetime

http://php.net/manual/en/session.configu...robability

I believe they just wanted to follow the PHP best practices instead of reinventing the wheel.

I would give that a try first.

DMyers

https://github.com/ProjectOrangeBox / https://github.com/dmyers2004

In /Session/Session.php on line 117 array($class, 'gc') you can see they setup the garage collector.

I'm pretty sure this simply follows php's php.ini

session.gc_probability
session.gc_divisor
session.gc_maxlifetime

http://php.net/manual/en/session.configu...robability

I believe they just wanted to follow the PHP best practices instead of reinventing the wheel.

I would give that a try first.

DMyers

Best practices? I wouldn't say that.

But there is some truth to not reinventing the wheel ... If you know how to do something in raw PHP, you shouldn't be asking how to do it in framework X, so there you have it.

This is unknown territory for me. Maybe I should dive into that.
About re-inventing the wheel: why does CI have a session library in the first place? Isn't that just for convenience? So why not providing a method for cleaning up session related garbage?

The session library controls the mechanism for storage of the session data, specifically a driver system which allows individual sites to specify whether sessions are stored in files, the database, etc.

The library does provide a method for cleaning up session-related garbage, controlled by PHP's built-in garbage collection mechanism for sessions, which is, in turn, controlled by the referenced PHP settings.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

I have the same issue and already setting my php.ini vars and the number of rows in my session table still growing up, I guess that the solution could be extend the library to execute a cleanup. Really I hate this change on the session library

I checked the php.ini in my development environment and found that these were set to:

Code:

session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

Note: the comments in the file indicate that these are not the default values, but, I don't remember ever actually changing these values, and these lines were not commented out.

This pretty much ensured that my sessions were never cleaned up, and, sure enough, I had about 70 sessions saved on my machine. I changed session.gc_probability to 1, but the gc_divisor value of 1000 ensured that it was pretty unlikely (0.1% chance) I would ever see it cleanup. So, I dropped gc_divisor down to 10 just to make sure I would see it happen in a relatively short period of time. The next time I checked the sessions table in my database, the number of rows was down to 8.

Of course, the gc_maxlifetime value comes into play here, too, because it will be a little while before I have a chance of seeing it happen again. Also, remember to restart apache after changing these values.

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide

I checked the php.ini in my development environment and found that these were set to:

Code:

session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

Note: the comments in the file indicate that these are not the default values, but, I don't remember ever actually changing these values, and these lines were not commented out.

This pretty much ensured that my sessions were never cleaned up, and, sure enough, I had about 70 sessions saved on my machine. I changed session.gc_probability to 1, but the gc_divisor value of 1000 ensured that it was pretty unlikely (0.1% chance) I would ever see it cleanup. So, I dropped gc_divisor down to 10 just to make sure I would see it happen in a relatively short period of time. The next time I checked the sessions table in my database, the number of rows was down to 8.

Of course, the gc_maxlifetime value comes into play here, too, because it will be a little while before I have a chance of seeing it happen again. Also, remember to restart apache after changing these values.

I recall a report about Debian-based distributions using their own crontab mechanism to purge inactive sessions ... didn't realize they actually disabled PHP's session GC though.

I am also facing same problem, within 2 day of website launch Session table goes over 1GB

There should be some out-of-box mechanism to clean up old records.