Have Plesk and PHP sessions time out earlier than expected?
I just went through a two week long troubleshooting process to try and find the cause of sessions timing out earlier than expected. My PHP session config is as follows, and should definitely be the first place you look for an issue like this:
session.cookie_lifetime 0
session.cookie_path /
session.entropy_length 32
session.gc_divisor 1000
session.gc_maxlifetime 35000
session.gc_probability 1
This indicates that cookies should expire only after the browser closes, not after a given timeframe (cookie_lifetime 0) and that when the session is inactive (the user left the browser window opened and logged in) it should take roughly 9.7 hours (3500 seconds) before a time out with a 0.1% chance (gc_probability/gc_divisor) of a timeout occurring in that timeframe.
Yet my sessions were still timing out after about an hour.
After much hunting around I finally found the Plesk utility called maxlifetime located at /usr/lib64/plesk-9.0/ which is called every hour by this cron script: /etc/cron.hourly/plesk-php-cleanuper
The maxlifetime script scans for all existing php.ini files, finds the session.gc_maxlifetime value that is the largest configured value, then uses it to determine when to actually clear out old sessions from the session directory (/var/lib/php/session).
The problem is that maxlifetime does not account for custom PHP configuration values defined per-domain.
This means that even if you’ve configured session.gc_maxlifetime to be longer than 1 hour for any given domain within Plesk, it will still have its session files cleared somewhere between the default of 24 minutes and 60 minutes. (The range is variable because it depends on the differential between when the session was created and when the cron script runs, which is hourly by default due to its location in /etc/cron.hourly).
Run the following in shell to set the default php.ini file in the system to have its maxlifetime value = 24 hours.
sed -i '/^session.gc_maxlifetime = 1440/s/1440/86400/' /etc/php.ini
This is better than disabling or removing the script entirely because there can be performance issues with having too many old session files. It also means that you’ll be able to set timeout values greater than 24 minutes and shorter than 1 day that are still effective. If you want sessions that last longer than a day, you can multiply the number 86400 by the number of days that you want the sessions to survive.
You can check out our report on this issue in the Plesk forums here.
Posted in Code
About Websavers
Websavers provides web services like Canadian WordPress Hosting and VPS Hosting to customers all over the globe, from hometown Halifax, CA to Auckland, NZ.
If this article helped you, our web services surely will as well! We might just be the perfect fit for you.
Many thanks Jordan, your article solved a 2 month old problem we had with expiring sessions.
Happy to help!
[…] https://websavers.ca/plesk-php-sessions-timing-earlier-expected […]
Muchas gracias!
Estoy casi seguro que esto solventara el problema.
Estamos muy agradecidos con tu información.
Saludos!
De nada, Jesús! Estoy feliz que ayudalo 🙂
Sadly enough this is still valid as of 2020.
Thanks for the info.
Hey Rob, I’m glad my findings could be of service!
You can also change the “max” value in /usr/lib64/plesk-9.0/maxlifetime :
max=7200 (for exemple if you want a session timeout of 2 hours).
This is the variable used by the script /etc/cron.hourly/plesk-php-cleanuper.
Also consider to set session.gc_probability = 0 in your php.ini files (since sessions are cleaned by Plesk script).
Ludo
Excellent additions; thanks for the tips!
Thank you for the information 🙂
I’ve struggled many times with session issues over the years. I just moved web servers and all my knowledge wasn’t working, but your information was the missing piece!
Hey Murray,
Happy to hear it! When you’re next looking for a new virtual server, come check us out!
-Jordan
Thank you so much Jordan. I’ve been looking for a solution to this for a week now and I’m on Onyx so clearly they haven’t done anything to resolve this??? I’ve just implemented your fix, haven’t tested but I have no doubt this is the solution I was looking for. I’ll just finish testing and then post a link to your solution on Stack Overflow.
My pleasure Sam!