Revolution: Sessions garbage collector not used?

[bezumkin]

Hello!

I found a method modSessionHandler::gc(), that must delete old sessions, but it seems that it is never used.

I think, that is why my modx_session table takes 1gb and contains 500 000 records.

For me i wrote a simple script, that randomly deletes old sessions:

$rand = rand(1, 100);
if ($rand === 1) {
    $gcMaxlifetime = (integer) $modx->getOption('session_gc_maxlifetime', null, @ini_get('session.gc_maxlifetime'), true);
    $access = time() - $gcMaxlifetime;
    $modx->exec("
        DELETE FROM {$modx->getTableName('modSession')} WHERE `access` < {$access};
        OPTIMIZE TABLE {$modx->getTableName('modSession')};
    ");
}

[opengeek]

It may seem that it is never called, but the gc() method is called automatically (based on some other session configuration settings) by PHP when writing/closing the session. And it has that many records because you have sessions enabled for all anonymous users (web and other front-end Contexts) with each session living at least as long as the default session_gc_maxlifetime setting in MODX Revolution. It is set at 604800 (in seconds) by default. That's 7 days every session will live for; at least.

You can reduce this setting and/or disable sessions in your front-end Contexts (if you don't need session functionality) to reduce the size of the session database. Or you can configure another PHP session handler if you prefer.

If you do have evidence that it is not being triggered properly, I will be glad to reconsider this issue.

[bezumkin]

Ok, sounds good.

But why I see old session in my database?

And if I manually run the modSessionHandler::gc() - it removes that sessions?

Maybe, it is because of default Ubuntu settings (session.gc_probability = 0)?

[opengeek]

Likely so as that means you have a 0 in session.gc_divisor chance of it being garbage collected. The default should be a 1 in 100 chance (100 is the default for session.gc_divisor) according the documentation at http://www.php.net/manual/en/session.configuration.php#ini.session.gc-probability.

[bezumkin]

Thanks, now it seems clear to me. I need to adjust server settings and look for changes.

Maybe we need to add some check of session.gc_probability in handler? Ubuntu - is number one distributive in GNU/Linux world. https://bugs.launchpad.net/ubuntu/+source/php5/+bug/316441

[bezumkin]

Confirm!
session.gc_probability = 1 solved the issue.

All Ubuntu users, you need modify this setting in your php.ini!

[opengeek]

Wow, that is a much larger problem than I thought. In fact, it seems modx.com has the same problem itself! Sigh...

[exside]

thank you so much for pointing that out! I actually also have that problem with several sites and it's causing the site to get slower and slower, don't know why, but when I clear the sessions its fast again^^

[jpdevries]

@exside the issue is probably your sessions table growing incredibly large

[exside]

exactly! got 100000s of entries over time and it's exactly the problem that anonymous sessions are stored there (in my case for no purpose), so it would be interesting to know HOW to disable the sessions for anonymous users (as jason mentioned)!

[opengeek]

See http://develop.modx.com/blog/2012/04/05/new-for-2.2.1-session-less-contexts/ for a description of how to disable sessions for a Context.

[exside]

I will immediately do this on smaller sites, thanks for the hint!

I was just thinking about a bit more complex site, basically in 99% of the cases the frontend is accessed, it is via anonymous session, so that would also make sense there, but in some rare cases (for example download form submissions when logged into the manager etc.) the site needs the session to show other content...so I guess the session_enabled context setting is not the way to go here. What I'm looking for is a way to just prevent the anonymous sessions but work normally if somebody logs into the manager first...is that possible somehow?

Would a snippet that calls $modx->getAuthenticatedUser('mgr') still work in that case? Basically if a editor/user is logged into the manager first and I then call this method, that should still be true, no matter if sessions are on or off right?

[exside]

I actually just tried the session_enable = 0 but the main problem that arises is that a preview of not published resources (from the manager) is not possible anymore, this basically renders the setting unusable in a site that is edited on a regular basis =/...don't think there is anything that could be changed to make that work, right (bc there's just no session read in the frontend/context)?

[azeller]

bezumkin: thanks for pointing this out. the worst part is actually that the documentation is misleading.

; Default Value: 1
; Development Value: 1
; Production Value: 1
; http://php.net/session.gc-probability
session.gc_probability = 0

That was in my (untouched) php.ini for PHP7

[OptimusCrime]

It is the distro that overrides this value. Debian does this as well. CentOS does not, as far as I can remember. It could be a good idea to include this in the documentation somewhere, as this is rather important.

[YoungRus]

Sessions are deleted only after changes here

MODx settings

• session_cookie_lifetime = 1440
• session_gc_maxlifetime = 1440

CentOS7 - PHP.ini

• session.gc_probability = 1