Session cleaning

[apeisa]

How does pw cleans session files or does it at all?

I found out that I had few hundred megabytes of session files at /site/assets/sessions/ and oldest ones were from the day the site was build.

Should I build custom session cleaning, is this a bug or am I maybe using sessions wrong?

[Adam Kiss]

Is it PW2.0 or 2.1rc?

Because if it's 2.1rc, I'm inclined to say it's a bug, since yesterday I raised rather important issue in 2.1. With 2.0, I'd say do your own session cleaning

[apeisa]

2.1 (and version about month ago, should update).

[ryan]

Both versions just uses PHP's session functions, so ProcessWire isn't involved in the clearing of the session files. PHP's garbage collection should take care of them. But it sounds like it's not? I'll check around on some of my sites to see if the same thing is happening there. 

[apeisa]

There are almost 6 months old session files. Not sure about my php settings, so need to check that also. And Ryan, welcome back!

[ryan]

Tested on a couple of sites here and PHP's garbage collector seems to be doing it's job. I don't have any session files older than 24 hours. If it helps, I've attached a screenshot from the phpinfo() session section on one of those sites. It might be good to compare to yours and see what's different. I'm guessing it's something in the garbage collection (gc_) options. Please let me know what you find. We can always override PHP's values for these (currently we don't override the gc_ options).  

[apeisa]

Thanks Ryan.

I compared the settings and there are few differences:

Registered save handlers = files user

Registered serializer handlers = php php_binary wddx

session.bug_compat_42 = Off

session.bug_compat_warn = Off

session.gc_divisor = 1000

session.hash_bits_per_character = 5

session.save_path = /var/lib/php5

session.use_only_cookies = On

[ryan]

The gc_divisor is one potential issue, though I don't think it would account for it entirely. But here's what php.net has to say about it:

session.gc_divisor coupled with session.gc_probability defines the probability that the gc (garbage collection) process is started on every session initialization. The probability is calculated by using gc_probability/gc_divisor, e.g. 1/100 means there is a 1% chance that the GC process starts on each request. session.gc_divisor defaults to 100.

So in your case with a gc_divisor of 1000 there is significantly less chance that the garbage collection will run... perhaps such a small chance that it almost never happens. Though I've not experimented with this setting, so can't say for sure.

Here's another thing I found:

Note: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other filesystem where atime tracking is not available. Since PHP 4.2.3 it has used mtime (modified date) instead of atime. So, you won't have problems with filesystems where atime tracking is not available.

If I'm reading this right, we don't have to be concerned about this issue. But it seems a bit strange they way they mentioned "Oh by the way, Since PHP 4.2.3...", as a side note at the end, so I'm a little suspicious of this. Is your file system fat?

[ryan]

I found this in Drupal 7's source:

/**
* Some distributions of Linux (most notably Debian) ship their PHP
* installations with garbage collection (gc) disabled. Since Drupal depends on
* PHP's garbage collection for clearing sessions, ensure that garbage
* collection occurs by using the most common settings.
*/
ini_set('session.gc_probability', 1);
ini_set('session.gc_divisor', 100);

I'm thinking perhaps we should add the same to PW's default config file.

[apeisa]

Thanks Ryan. That probably is it, since we use Ubuntu (debian).

Strange thing is that garbage collection seems to work now on one site. We manually removed most of the files about week ago, but now oldest ones are little bit over 24 hours ago... But others are not working... so maybe there is that probability at work.

I'll follow how this progress few days without adding those lines, and will add those later to see better picture of what is going on.

[Soma]

I experience the same, session log files stay all the way the first login. I recognized once I downloaded site folder and was impressed by how many files there is. Is the any insight on this?

[ryan]

I could be wrong, but I think your session.gc_probability being set to "0" means that the session garbage collection will never run. This should probably be changed to 1 (the default for PHP). But as previously noted, Drupal sets both gc_probability and gc_divisor, so I've been wondering if PW should too.