severity 621360 wishlist tags 621360 +wontfix thank you Hi David,
you seem to misunderstand the concept of the cron job. The cron job itself serves no purpose, but it has to be there since the /var/lib/php5 should not be readable by www-data (or any other user) for security reasons - you certainly don't want any script running under www-data user to be able to read other webs sessions. As for SugarCRM you're free to re-enable the GC, disable the cron job or set the session directory to some other and do whatever modification (like just setting the timeout to 6 hours, etc) you need. Also if you feel that the description in php5-common README.Debian is not sufficient, we are certainly open to any suggestions how to improve the text. O. On Wed, Apr 6, 2011 at 22:49, David Norris <[email protected]> wrote: > Package: php5 > Version: 5.3.2-1ubuntu4.2 > Severity: important > > The cron job assumes that all PHP scripts use the global max lifetime value. > I have never, once, ever seen a PHP script that recommends using the default > settings as a good idea. For example, I am using SugarCRM. The cron job is > blindly vaporizing session data every 30 minutes despite the fact that > SugarCRM changes this value locally. The effect this has is devastating to > the operation of SugarCRM. Ajax calls into the application often get > redirected to a login dialog due the the session disappearing at > inappropriate times. When this occurs it causes data loss in the application. > > Also, it seems inappropriate to me to change the global php.ini setting at > all for any reason. Those are very reasonable defaults. However, within > Apache you may want to locally modify the max lifetime for a particular vhost > to a value which is unreasonable to other vhosts. Such as SugarCRM where we > want sessions to last an entire 8 hour shift. > > I question whether this cron job serves any purpose at this point. It seems > to be working around a bug in the Debian PHP 4.0 package from2004. I have > been testing today and PHP 5.3 appears to be garbage collecting sessions > appropriately. The permissions seem to suggest there should be no problems, > as well. > > The original Debian Bugs which prompted the addition of the cron job and move > of session data to /var/lib/php[4|5] are #256831 and #257111 > > > Sorry, the system info is probably a bit ugly as this is an Ubuntu system but > the problem originates from Debian so I chose to submit to debian bts. > > -- System Information: > Debian Release: squeeze/sid > APT prefers lucid-updates > APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500, 'lucid') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.32-21-server (SMP w/2 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > > Versions of packages php5 depends on: > ii libapache2-mod-php5 5.3.2-1ubuntu4.2 server-side, HTML-embedded > scripti > ii php5-common 5.3.2-1ubuntu4.2 Common files for packages built > fr > > php5 recommends no packages. > > php5 suggests no packages. > > -- no debconf information > > > > _______________________________________________ > pkg-php-maint mailing list > [email protected] > http://lists.alioth.debian.org/mailman/listinfo/pkg-php-maint > -- Ondřej Surý <[email protected]> http://blog.rfc1925.org/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
