Description of problem: The script at /usr/lib64/php/maxlifetime, which is used by /etc/cron.d/php to delete old/expired sessions, has a hard-coded limit of 24 minutes. This script then disregards any PHP session lifetime (session.gc_maxlifetime) value greater than 24 minutes, but this limit isn't documented or explained anywhere. This limit should be well-documented or removed.
CC: (none) => luigiwalser, oe, oliver.bgr
Confirmed, and easy to fix. /usr/lib/php/maxlifetime just needs to look at /etc/php.ini, in addition to, or instead of /etc/php.d/*_session.ini. Considering the only file matching that wildcard is 47_session.ini from php-session, which just contains: extension = session.so I'd think it'd be fine to just have the script look at php.ini. In the php package source, this script is SOURCES/maxlifetime. Oden, could we fix this for the next set of php updates?
Version: 2 => CauldronWhiteboard: (none) => MGA3TOO, MGA2TOO
This comes from debian and solved an issue years and years ago. However, after looking at the specific problem you should be able to define session.gc_maxlifetime in /etc/php.d/47_session.ini like so: echo "session.gc_maxlifetime = 2880" >> /etc/php.d/47_session.ini Then after running /usr/lib64/php/maxlifetime it will say 48 Is this good enough?
Sure that works as a workaround, but why not fix the script in our package to read from the correct file?
Because (In reply to David Walser from comment #3) > Sure that works as a workaround, but why not fix the script in our package > to read from the correct file? Because there are four possible ini files that could contain different settings. /etc/php-cli.ini /etc/php.ini /etc/php-cgi-fcgi.ini /etc/php-fpm-fcgi.ini All these will use /etc/php.d/47_session.ini.
OK. Being that this script works globally, it should be running at the max of the settings in all of those files. Why not have it at least read those files and use the max setting from them, rather than assuming the sysadmin is going to copy the right value to 47_session.ini?
(In reply to David Walser from comment #5) > OK. Being that this script works globally, it should be running at the max > of the settings in all of those files. Why not have it at least read those > files and use the max setting from them, rather than assuming the sysadmin > is going to copy the right value to 47_session.ini? Because this is the first time anyone notice or file a bug report about it. But sure, I can add this value in /etc/php.d/47_session.ini and also correct the "documentation" in /etc/php.ini
You could, but wouldn't it be easier to fix the script? That would seem to make more sense, and be better for syadmins too.
fixed in r467724, r467725, r467726
(In reply to David Walser from comment #7) > You could, but wouldn't it be easier to fix the script? That would seem to > make more sense, and be better for syadmins too. It will not be so easy since there is no way to tell what interpreter is used, and/or which php*ini file is used. /usr/bin/php is not /usr/bin/php-cgi, nor is it /usr/sbin/php-fpm or /usr/lib64/httpd/modules/mod_php.so. All of them can be installed at the same time and also being used differently.
(In reply to Oden Eriksson from comment #9) > (In reply to David Walser from comment #7) > > You could, but wouldn't it be easier to fix the script? That would seem to > > make more sense, and be better for syadmins too. > > It will not be so easy since there is no way to tell what interpreter is > used, and/or which php*ini file is used. /usr/bin/php is not > /usr/bin/php-cgi, nor is it /usr/sbin/php-fpm or > /usr/lib64/httpd/modules/mod_php.so. All of them can be installed at the > same time and also being used differently. Right, but that doesn't matter. The script just runs regardless of which you're using, or what your settings are. Like I said before, it should just use the max of any of them.
Depends on: (none) => 10997
Fixed in the update for Bug 10997: http://advisories.mageia.org/MGASA-2013-0264.html
Status: NEW => RESOLVEDResolution: (none) => FIXED