• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • We are looking for U.S.-based freelancer or agency working with SEO or WordPress for a quick 30-min interviews to gather feedback on XOVI, a successful German SEO tool we’re looking to launch in the U.S.
    If you qualify and participate, you’ll receive a $30 Amazon gift card as a thank-you. Please apply here. Thanks for helping shape a better SEO product for agencies!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    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. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

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