• Introducing WebPros Cloud - a fully managed infrastructure platform purpose-built to simplify the deployment of WebPros products !  WebPros Cloud enables you to easily deliver WebPros solutions — without the complexity of managing the infrastructure.
    Join the pilot program today!
  • Support for BIND DNS has been removed from Plesk for Windows due to security and maintenance risks.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS.

plesk-php-cleanuper creates PHP session timeout issues

websavers

Regular Pleskian
I've set session.gc_maxlifetime to a higher value in Plesk's PHP Settings so that when a user is logged in, they won't be auto-timed out after 24 minutes (or so). Except I found that auto-logout always occurred within about an hour, even though sessions with a cookie value set to 0 meant it should last until the browser restarts.

After many hours of troubleshooting, I've finally found the cause of my PHP session timeout issues.

On CentOS the plesk-php-cleanuper script runs hourly (/etc/cron.hourly/plesk-php-cleanuper). This would be fine if it worked as it should, but the script/config located at /usr/lib64/plesk-9.0/maxlifetime doesn't appear to be taking any custom configurations, or PHP INI's within the /opt/plesk/* custom PHP versions into account.

As a workaround, I moved the script from /etc/cron.hourly to /etc/cron.weekly. You could probably get away with daily.

BUT the real solution here MIGHT be for the Plesk devs to fix the script. I say might because it's going to get more and more tricky as you add more Plesk versions. You'll need for the script to not only scan for php.ini files within /opt/plesk/php/*/etc but also /opt/plesk/php/*/etc/php-fpm.d/*.conf (where the value needs to be parsed differently as it looks like this: php_value[session.gc_maxlifetime] = 35000 ).

It may be a better solution for Plesk to simply move the script to run daily? The downside to this is that it's not accurate; it's not cleaning up the sessions according to the user specified value.

Perhaps instead of trying to read the value from a potentially large number of config files, it would be simpler to set a sane default of 24 hours and use that; it's likely to be higher than most people ever require, but still accomplishes successfully session file garbage collection.

Just my 2c, but either way, this needs to be fixed.

-Jordan
 
Back
Top