session.gc_maxlifetime

[keat63]

Whats the safest maximum this can be increased to.
By default its configured for 1440 seconds (24 minutes).
Iv'e increased it to 604,800 for inital testing. (7 days)

Trying to determine if this may be the cause of an issue that we see on some of our OS commerce sites.

 

[cPanelMichael]

Hello,

There's some discussion of this option on the following StackOverflow URL:

PHP : What is the default lifetime of a session

Could you expand upon the issue you are facing with your OS commerce websites? Note that we introduced some changes to how PHP sessions are handled in cPanel 64. You can read more about this under the "session.save_path" section at:

MultiPHP INI Editor for WHM - Documentation - cPanel Documentation

Thank you.

 

[keat63]

I saw the stackoverflow thing earlier today, but it didn't particularly answer my query.

Here goes:

As a customer, if I add items to my cart, then walk away but leave the browser open and return about 40 minutes later, when I click the checkout or continue button, it should send me to a payment page, but instead the cart contents empty.


I note in PHP info that the local setting for session.gc.maxlifetime is 7 days, but the global setting is 24 minutes.
By increasing the global setting to 7 days, the problem appears to go away.
I'm still a little confused why the local setting for 7 days appears to be over ridden by the global setting of 24 minutes. (maybe this is the real issue)

I'm still testing, however my preliminary results would indicate that changing the global setting fixes the fault.

I'm working closely with the cart coders in case they can do something at their end, as I see this setting appears to be a stock config, so has implications with this particular software world wide (i guess)

 

[keat63]

I've done a number of tests over the weekend with session.gc_maxlifetime configured for 24mins vs 24hours.
If set for 24 minutes I can quite easily cause a cart to empty it's contents.
Leave the browser window open, untouched. Come back 40 minutes later, click continue and the cart empties.

With session.gc_maxlifetime configured for 24 hours, this doesn't happen.

 

[rpvw]

Hi keat63,

You may find this thread helpful on the oscommerce forums

 

[keat63]

Sounds very similar to my issue.
I believe my particular cart should be taking this in to account as there's reference to overriding these defaults in a class file.
But for reasons beyond my understanding, this doesn't seem to be working.

I'm confident the the support team will come up with a solution, but in the meantime, I wondered what a safe threshold should be.

 

[cPanelMichael]

Hello,

Could you confirm if this system uses EasyApache 3, or EasyApache 4? Also, when you upload a PHPINFO file to the same document root that the OSCommerce script uses, what do you see for the "session.gc_maxlifetime" value (both local and master values)?

Thank you.

 

[keat63]

EA4

PHP info in the cart admin area indicates session.gc_maxlifetime to have a value of 604800 local and 1440 Master.

I increased the master value in my PHP config to 259200, which fixes my initial problem, but doesn't really help others.

I found this, which needs clarification if anyone knows.

Taken from PHP: Runtime Configuration - Manual

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.


Based on this, if we assume that my script is configured to garbage clean after 604800 (7 days), but another script on the same server is set for 'something else', then could 'the other script' be deleting this session ??

If so, then what are the implications for shared hosting ?


All my session data is in the same place, as the session data settings are as they came when i installed it

 

[cPanelMichael]

Hello,

Were you able to review the "session.save_path" section of the document referenced in my earlier post? Here's the link:

MultiPHP INI Editor for WHM - Documentation - cPanel Documentation

It provides information about how PHP sessions are handled differently with EasyApache 4 as of cPanel version 64.

Thank you.

 

[keat63]

Hi Michael.

The session save path is how it came out of the box which is var/cpanel/php/sessions/ea-php70.
I see many sessions being stored in there with thier own ownership.

I think I've ruled out, other scripts deleting GC sessions, as my server has the same script on all domains.

What i'm now struggling to comprehend is why the local setting for sessions.gc_maxlifetime is not being honoured.
And if sessions.gc_maxlifetime local settings are being ignored, then quite possibly, so are other local settings.

 

[Brooky A]

Hi guys, I'm watching this thread too as I'm keen to see the outcome.

Referring to the notes in your link concerning the MultiPHP INI editor I read;

"The session files are cleaned by a root-run cron job."

It seems from our findings (as I have worked closely with Keaton on this) is that local garbage collection settings via PHP ini_set are ignored and the script runs listening to the master value only.

Could this be a cPanel bug? I'm not sure how the root run script can determine which session files should last longer than others. On a shared server with domain x using the master value (24 mins) and domain y using a local value (say 7 days) how they can be treated individually by the garbage collection script?

Hope that makes sense..

 

[cPanelMichael]

Referring to the notes in your link concerning the MultiPHP INI editor I read;

"The session files are cleaned by a root-run cron job."

It seems from our findings (as I have worked closely with Keaton on this) is that local garbage collection settings via PHP ini_set are ignored and the script runs listening to the master value only.

Hello,

Thank you for the additional information. The behavior you noticed is by design. The "/usr/local/cpanel/scripts/clean_user_php_sessions" script will only recognize the global "session.gc_maxlifetime" PHP configuration value configured for each version of PHP. If a custom value for "session.gc_maxlifetime" is preferred for an individual account, then the workaround is to also configure a custom "session.save_path" value for the account. This will allow PHP to handle the session cleanup, as opposed to the "/usr/local/cpanel/scripts/clean_user_php_sessions" script.

Thanks!

 

[keat63]

Something we can play with on my test domain.
Does this custom save path have to be anywhere in particular, can this be dropped inside it's own domain ?

 

[Brooky A]

It can be anywhere but if in the public folder directory listing should be disabled and maybe it would be a good idea to add a rule to the .htaccess file to deny access to "sess_*" files.

My concern is how these session files can be cleaned up. The following PHP code doesn't always work due to file permissions.

$files = glob('/path/to/sessions/sess_*');
$now   = time();
foreach ($files as $file) {
    if ($now - filemtime($file) >= ini_get('session.gc_maxlifetime')) {
        unlink($file);
    }
}

 

[cPanelMichael]

My concern is how these session files can be cleaned up. The following PHP code doesn't always work due to file permissions.

Here's a quote from our documentation related to this:

Do not change the session.save_path to /tmp or a directory that other users or programs use. If you change the session.save_path to another directory, the directory's permissions will be changed to 4733. This will likely break other programs' functionality. If /tmp must be used, create a subdirectory under /tmp to hold the PHP session files.

Thank you.

 

[Brooky A]

Thats crystal clear now thanks Michael. Keep up the good work.

 

[keat63]

I also have a hosted plan with a number of addon domains.
I see in my hosted cpanel that the session save path is configured for /tmp.
However, I assume this is myaccount/tmp and not hosts_server/tmp (in effect my own tmp folder)
My host have kindly increased sessions.gc_maxlifetime on my plan, and I can see this reflected in phpinfo, however, the server still over ruled and removed my test session after 30 minutes.

As a server owner, I can resolve this issue by changing my global server value, but on a hosted plan, it seems I cannot.

How would we over come this ?

 

[Brooky A]

I would suggest something above the public_html folder.

e.g. /home/{user}/sessions

Then write a script for garbage collection:
cleanup php session files