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 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:

  1. Custom PHP configuration values definable within Plesk, and
  2. 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.

About Jordan Schelew

Jordan has been working with computers, security, and network systems since the 90s and is a managing partner at Websavers Inc. As a founder of the company, he's been in the web tech space for over 15 years.

8 Comments

  1. Rob Gelders on January 13, 2020 at 4:08 am

    Sadly enough this is still valid as of 2020.
    Thanks for the info.

    • Jordan Schelew on January 13, 2020 at 6:21 pm

      Hey Rob, I’m glad my findings could be of service!

  2. Ludovic Klein on September 20, 2018 at 4:57 am

    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

  3. Murray on March 9, 2017 at 1:04 am

    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!

    • Jordan Schelew on March 9, 2017 at 12:30 pm

      Hey Murray,

      Happy to hear it! When you’re next looking for a new virtual server, come check us out!

      -Jordan

  4. Sam on January 19, 2017 at 4:22 pm

    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.

Leave a Comment