Blog

Most web sites have sessions for their users. You know, those things that keep track of your information temporarily and log you out if you have been inactive for too long.  Well, PHP has session management through a process called garbage collection.  The problem is, especially if you are using CakePHP, you may not be getting your session management quite the way you think.

You see, in Cake, the things that you would think to set are the Session.timeout and Security.level values in the core.php file to tell Cake when a session is no longer valid. For example, if Session.timeout is set to 300 and Security.level is set to ‘low’, then you would expect your sessions to time out in 300×300 seconds, or 25 hours.  Unfortunately, that is only half of what happens if your settings also include having PHP manage your sessions (i.e., Session.save is set to php in the core.php file, which is the default). PHP has it’s own variables in the php.ini file that determine when a session _actually_ gets killed.

In your php.ini file, the variables you need to look at are:
session.gc_probability, session.gc_divisor, and session.gc_maxlifetime

On my system, they look like this:
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440

I am also using the session.save_path variable to put the session files in a subdirectory to keep them managable (this will be important later).

Now, here is the fun part.  session.gc_maxlifetime defines the number of seconds after which stored data will be seen as “garbage” and will get cleaned up when the garbage collection process runs.  That means that the above config will clean session files older than 1440 seconds (24 minutes) when garbage collection runs.

However, the session.gc_probability and session.gc_divisor variables also play a part in this.  These two variables define the likelihood that garbage collection will run on every session init.  In this case, there is a 1% chance (i.e., session.gc_probability/session.gc_divisor) that garbage collection will take place on any given session activity. This is important, because you have to _manually_ run the garbage collection process if you are using the session.save_path variable to store the session files in a subdirectory.

What this means is, even if you don’t run the garbage collection yourself, the gc_probability has a chance to step in and run it anyway. That’s not necessarily a bad thing, because you don’t want session files hanging around forever, but the behavior can look a little odd if you aren’t expecting it.

Now, if you have been paying attention so far, you will also notice that 24 minutes is a LOT shorter than the 25 hours that is defined in the CakePHP core.php file, and that’s the root of the problem.  What is illustrated here is the fact that the php.ini file is what’s really managing your sessions, not the core.php file settings.  The PHP settings are what really matter in this case, and can lead to sessions getting destroyed much earlier than you think they should, based on core.php.

So, if you are using sessions in your CakePHP application, just make sure that you are aware of the underlying PHP configuration that may be interfering with your CakePHP config.