Lots of Sessions

[Pete]

Hi folks

So I've got a very active PW site up and running (finally) but I'm not ready to link to it until I finish my snag list

I was just looking through the log files, and noticed the site/assets/sessions folder - it has almost 3,000 session files in it already and the site's not been online 24 hours yet!

Are these required for something? They all seem to contain the same content:

Session|a:0:{}

Seems a bit pointless, and I'm not sure what they relate to - any ideas anyone?

[apeisa]

Pete: similar to this http://processwire.com/talk/topic/337-session-cleaning/page__hl__sessions__fromsearch__1

We don't have this problem anymore and I don't remember actual solution, but maybe @vsulin will drop in and tell? It was something about server settings and ubuntu defaults anyway...

[Pete]

Cheers for that - it only appears to be keeping about 24 hours of them which is how it's suposed to work I see. Fortunately that stops it at 5,600 files

[ryan]

I'm going to be adding an option to store sessions in the DB soon too, so this will be another alternative option for those that want it.

[Pete]

That's good to know ryan, even though I'm not sure if it's doing any harm with that many files. I was just curious as to why it needed so many empty files. Is it more of a "just in case" thing in case any session vars get set or something?

[ryan]

This is one of those things that has to do with the inner-workings of PHP's session system. I've not attempted to override PHP's session storage mechanisms with PW (other than where it places the files) so this is probably a question for Rasmus Lerdorf. But I believe they are just placeholder files to track an active session, and they won't contain any significant data in them unless you specifically set it to the $session var. In lieu of tracking data, the filename itself is likely of more importance since it relates the session ID from the user's cookie to the session ID on the server. Of course, once we provide the option of DB session storage, we will be taking over more control from PHP in this area... at least when DB session storage is selected.

[netcarver]

Ryan,

check out flourish's handling of sessions for some inspiration too. Though not fully documented at the front-of-site, it allows different session storage mechanisms via the setBackend() static call. I have to add, I haven't used this personally but thought I'd throw this into the ring if you are about to do some research.

[joe_g]

Hello there. I'm currently deleteing 160.000 session files : )

rgds,

J

[Soma]

If the garbage collector on server is set wrong this can happen.

The good news, there's is now DB session module in PW since some versions in dev already to handle session via DB. Just install it. https://github.com/ryancramerdesign/ProcessWire/tree/dev/wire/modules/Session

[ryan]

If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file:

ini_set("session.gc_probability", 1);
ini_set("session.gc_divisor", 100);

[joe_g]

thanks! Will try this.

[bernhard]

hi everyone,

unfortunately i came up to this problem as well. server is Ubuntu 12.04.5 LTS; i had > 140.000 files in the sessions folder

i have these two lines in my _init.php file (basic intermediate profile structure)

ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);

phpinfo in one of my template files says this, so i guess the changes should be working

2 days ago i deleted all of the session files, but today i have again > 7000 files, oldest from the day before yesterday, so far over 24 hours old!

any ideas? thanks in advance!

[SiNNuT]

I would give it a little bit more time. It's not always true that no older files than 'current time - 86400 seconds' should exist.

probability/divisor = 1/100 = 1% : The garbage collector will run once per 100 new sessions, and then clear all files older than 86400.

Although, if you already have 7000 session files, it should be pretty close to exactly 86400 seconds.

[bernhard]

hmm... thank you sinnut for your fast reply! i'll give it some more days.

just for the record, i have >7500 files right now. lets see how that changes over the next days...

couldn't i also try to increase probability to 99 or 100? to make sure that it works and then change it back to 1?

[Martijn Geerts]

I vaguely remember there's an issue with the garbage collecting and session with Unbuntu. 

An option is to store sessions in the database. You've to enable Session Handler Database, you can enable that one in your module configuration.

[SiNNuT]

hmm... thank you sinnut for your fast reply! i'll give it some more days.

just for the record, i have >7500 files right now. lets see how that changes over the next days...

couldn't i also try to increase probability to 99 or 100? to make sure that it works and then change it back to 1?

Yes you could try setting the probability to '100' for testing purposes. Garbage collection *should* then run on every session start.

If that still does not work i'm not sure what's happening, because your settings seem to be fine. Maybe GC is somehow unable to delete in site/assets/sessions

[sforsman]

The reason for this is that you are setting the divisor and the probability after the execution of the garbage collector has already been decided (in other words, after the execution of session_start()). With Ubuntu your default value for the probability is 0, meaning it will never execute. You need to place those ini_set directives before the session is started. In ProcessWire one way to do this would be

wire()->addHookBefore("Session::init", function() { 
  ini_set('session.gc_probability', 1);
  ini_set('session.gc_divisor', 100);
}); 

You would need to place this inside an autoloading module though. Another way would be setting those inside your .htaccess with

php_value session.gc_divisor 100
php_value session.gc_probability 1

(depending on your host, this might not work)

Your last resort would be clearing them "manually" by adding this to your _init.php. Well basically you wouldn't even need a hook, you could just execute the code.

wire()->addHookAfter("ProcessPageView::finished", function() {
  $prob   = ini_get('session.gc_probability');
  $div    = ini_get('session.gc_divisor');
  $path   = ini_get('session.save_path'); 
  $expire = ini_get('session.gc_maxlifetime'); 

  if(rand(1,$div) <= $prob))
  {
    foreach(glob($path.DIRECTORY_SEPARATOR."sess_*") as $file)
    {
       if(filemtime($file) <= time() - $expire) unlink($file);
    }
  }
});

[SiNNuT]

Putting probablity and divisor in config.php worked for me on a ubuntu server.

[sforsman]

Putting probablity and divisor in config.php worked for me on a ubuntu server.

Yeah, that would work as well! Anywhere really that gets executed before session_start()

[bernhard]

hey guys, thank you!

it worked for me with the following values (for testing):

index.php

ini_set("session.gc_maxlifetime", 60); // changed $config->sessionExpireSeconds to 60

config.php

ini_set('session.gc_probability', 100); // 100% probability
ini_set('session.gc_divisor', 100);

----> it cleared all session files older than 60 seconds on every pageload.