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:
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 is supposed to scan for all existing php.ini files, find the session.gc_maxlifetime value that is the largest configured value, then use it to determine when to actually clear out old sessions from the session directory (typically /var/lib/php/session).
The problem is that maxlifetime must have been written prior to Plesk implementing two things:
- Custom PHP configuration values definable within Plesk, and
- The ability to install multiple PHP versions and allow your clients to select which one they’re using
I say this because the maxlifetime script only searches in standard OS-installed binary config locations (such as /etc/php.ini) for values of session.gc_maxlifetime.
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.
While it’s up to Plesk to repair their scripts to make them behave as they’re supposed to by taking additional php.ini locations into account (as well as php.conf config values in the case of domains using PHP-FPM), we can implement a workaround that’s a bit less elegant, but much simpler!
Simply run the following in shell to change the cron script from running hourly to daily:
mv /etc/cron.hourly/plesk-php-cleanuper /etc/cron.daily/
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, then you’ll probably want to move it to the /etc/cron.weekly folder instead.
You can check out our report on this issue in the Plesk forums here.