Huge number of session files?

I don't see problems here as each user session is stored in this folder. If you have several thousands of users in community, it's normal situation.

You can delete these files while migrating to server without problems, but all those who were logged in community will be automatically logged out

Hey Stas. My concern is more about the number of these files growing perpetually. When are they deleted?

Just to clarify, the community gets a lot of visitors, but very few logins and posts... are these sessions created for every single person that even visits the site without logging in?

Thanks!

Dan,

Session file creates for each unique user that visits your site.

PHP has own garbage collector to clean outdated session files when session cookie is expired.

So, do not worry about that.

Hey Paul. OK I think I understand what's happening...

See this explanation from php.ini - http://www.screencast.com/t/vo9hKf0WI98

So it looks like the garbage collection is only automatic if session files are stored in the directory.

This explains why there are literally 100,000 files in the session directory... there's no way that is normal; that means the garbage collection is not running. And that's eventually going to cause us a problem.

So do I need to set up a cron job for this? See the example in the screenshot above - Should I use their command but replace "+24" with "+14400"?

864000 / 60 = 14400.

Debian does not use the default garbage collector for sessions. Instead, it sets session.gc_probability to zero and it runs a cron job to clean up old session data in the default directory.

As a result, if your site sets a custom location with session_save_path() you also need to set a value for session.gc_probability, e.g.:

1. <?php
2. session_save_path('application/sessions');
3. ini_set('session.gc_probability', 1);
4. ?>

Otherwise, old files in 'application/sessions' will never get removed!

Make sure that directive session.gc_probabiliry is on.

1. session.gc_probability = 1

So, add to index.php the following code line:

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

before line:

1. require_once 'Singular/Bootstrap.php';

I hope that php allows you to override defaults by using ini_set.

Hi Paul!

Great news... I was mistaken, there WAS regular garbage collection done on the /application/sessions/ directory... the number of files is SO high because we've set it to 2 weeks AND there are a lot of visitors. But I verified the number of files is staying constant at that number... and grows AND shrinks. Screenshot: http://www.screencast.com/t/zsodDvtbm

So... the index.php addition above was not necessary, I am removing it now.

However... this brings me back to my question higher up in this discussion: https://help.useresponse.com/responses/login-remember-me-functionality ...

How can I make the 14 day login work WITHOUT setting "session.gc_maxlifetime" in the main system php.ini file?

Can we use a similar trick in the index.php file? I just don't understand why the custom session directory is being set fine by UR, but the "session.gc_maxlifetime" directive is not. :-)

Thanks!

Hi, Dan.

There is no way to implement rememberMe functionality without tuning "session.gc_maxlifetime" directive.

See this article that would confirm this. You need to change directive value to 1209600 in other words 14 days.

1. php_value session.gc_maxlifetime 1209600

Hey Paul.

Looks like I found the solution...

So the goal was to set gc_maxlifetime PER SITE, not for the entire server - so that a high gc_maxlifetime value is ONLY set for the UR sites.

So I reset gc_maxlifetime back to original small value in the main php.ini.

I found the solution here (last answer at the bottom): http://stackoverflow.com/questions/6075770/php-session-timeout

Here's what I've got in .htaccess in public_html of the UR site I'm trying to set it up for:

1. # set cookie lifetime (login remember me) to 14 days
2. #php_value session.cookie_lifetime = 0
3. #php_value session.gc_maxlifetime = 1440
4. php_value session.cookie_lifetime 864000
5. php_value session.gc_maxlifetime 864000

As a test I set gc_maxlifetime to half that value - and sure enough, GC deleted half the session files.

So I believe this is the answer... we'll see over the next few days for sure. :-)

FYI here's a great solution to "test" if the new values are taking per-site:

http://board.phpbuilder.com/showthread.php?10351057-RESOLVED-Session-timeout-set-in-htaccess (halfway down this page - the testing example).

Dan,

Yeah, if your server permissions allows you to override php settings via .htaccess it might works.

But...

If different scripts have different values of session.gc_maxlifetime but

share the same place for storing the session data then the script with

the minimum value will be cleaning the data. In this case, use this

directive together with session.save_path.

Hey guys!

This was working perfectly, but wanted you to know, since we updated to 2.3.3 last month - the "remember me" functionality stopped working.

I see what's happening - the actual php session files are now disappearing every 24 hours... and our server guys are completely stumped...

Could this be related to the new 2.3.3 install?

Dan,

Since version 2.3.0 and upper we have change nothing regarding login process.

I guess that your server/PHP configuration could change.

Try to inspect your php.ini.

Hey Paul... we have not made any changes to php.ini or any of our apache configuration... there were no changes to apache or php config. Here is the settings, as before: http://www.screencast.com/t/dayHiMhP2Y8Z

I believe this started right after we upgraded our Ask Dan & Jennifer UR Forums to the latest version (2.3.3) about 2 months ago. If you remember there were some upgrade problems in 2.3.1 I believe, and we had to roll back, then we upgraded finally to 2.3.3 and that worked fine.

Here's what I'm wondering... could this in any way be related to having 2 UR installations on our server - different versions? Our BlogPress UR Forums is still version 2.2.

Because starting 2 months or so ago when we upgraded Ask Dan & Jennifer UR Forums to 2.3.3, the "keep me logged in" stopped working on BOTH forums.

Thanks Paul.

Dan

Hey Paul! just to clarify - are you thinking this problem is due to having TWO installations of UR on same server?

Or related to having 2 different versions running - 2.2 (older) and newer 2.3.3.

it's strange that we had 2 UR installations running together for months with no "remember me" login problem, but only sometime after upgrading one to 2.3.3 the problem started...

Thanks!

Not the same server but the same domain mask or subdomains on this domain, therefore they can use the same cookies.

Maybe you need to upgrade both versions to resolve the login issue.

Hey Paul, thanks, that makes sense, it's worth trying. LOL it's a little frustrating since we just got the login stuff working a few months ago. :-)

OK, I tried to upgrade the 2.2 install and it says my license expired so didn't work...

Would you be able to re-enable our license on your end for a short time (say 2 weeks from today) so that the software update will work so we can see if we can make the login work again?

Thank you.

Dan,

You can generate a development licence using Licenses page by yourself.

Just type your domain name there (without http:// or https://) and click "Download" next link.

In order to get updates, please update your subscription

Hey guys.

@Paul - I downloaded the dev license so I could test upgrading our older install to latest UR version per your recommendation above, but it's not letting me do the upgrade - getting license error: http://www.screencast.com/t/YCKsI7Szy

You can see here the dev license is valid until September 30th: http://www.screencast.com/t/tIpqxb6qXnUe

@Stas - We currently have 2 installations and this "remember me" functionality stopped working in both installs since we upgraded to 2.3.3 one of them to two months ago before our license expired... trying to see if upgrading to latest version per Paul's recommendation will make it work again...

Thanks.

Dan

Hi, Dan.

Regarding dev license:

Make sure that you generate it without http(s):// or www. prefix.

Example:

If you want to use it on http://support.site.com/ you need to type "support.site.com" as license domain. If your domain is http://site.com/, type "site.com".

Dan,

Also, if your upgrade plan expired, you won't be able to use Auto-Upgrade feature. Just use manual upgrade

Hey Paul, this is how I did it... without http...

So the actual license screen shows license for "forums.blogsuccessjournal.com" so I just generated a dev license for same URL, exactly like this "forums.blogsuccessjournal.com"

But as @Stas just said now, the license plan is currently expired, we're just trying to make this work again to see if we can continue to have 2 installations. if so we will renew both this fall. :-)

Stas - if the plan is expired for our current license, would the dev license not allow us to upgrade for this test anyway?

lol i have no idea how to do manual upgrade, always used auto upgrade... :-) is it possible to even manually upgrade from 2.3.2 to 2.3.8?

Guys, if auto upgrade will not work even with a dev license, is there any way you can update our license to not be expired for another 2 weeks or so from now so that we can get this upgraded and see if this stubborn "remember me" issue is fixed? Thanks so much.

Dan,

You'll be able to upgrade, but only manually. Here are instructions

First try manual upgrade, as it's a problem to renew subscription manually to keep track of records.

You can renew subscription only for that license to check if it works fine... If you've migrated to different hosting - it should work

Thank you Stas, I understand, will do manual upgrade to see if that fixes it..

But I don't see the download link on my profile, sorry could you please tell me if I'm looking in the wrong place. :-)

http://www.screencast.com/t/X6OiCFn3Y

Download link is available if you have active subscription

Hi guys!

Does 3.0 remove the requirement for storing PHP session files on the server for logins?

Thanks!