Bug #76368 [Com]: Garbage collection configuration not handled correctly.

From: Date: Mon, 12 Feb 2024 01:31:31 +0000
Subject: Bug #76368 [Com]: Garbage collection configuration not handled correctly.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-246440@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76368&edit=1 ID: 76368 Comment by: nanocaiordo at gmail dot com Reported by: Alastair dot Growcott at dynautics dot com Summary: Garbage collection configuration not handled correctly. Status: Not a bug Type: Bug Package: Session related Operating System: Ubuntu PHP Version: 7.0.30 Block user comment: N Private report: N New Comment: It is not a PHP bug. /usr/lib/php/sessionclean doesn't read session.gc_probability but only session.gc_maxlifetime so it will clear session files older then session.gc_maxlifetime's value. Bug should be reported to the OS vendor. Previous Comments: ------------------------------------------------------------------------ [2018-05-23 13:31:38] requinix@php.net They're going to ask you where you made those php.ini changes. Did you notice that there are separate settings for the different SAPIs? Put the session changes into one file, then put a symlink to it in the various INI directories where you want the settings to apply. ------------------------------------------------------------------------ [2018-05-23 13:29:05] Alastair dot Growcott at dynautics dot com If the cron job does not use the settings then this is a real bug. But I think in fact it does. The cron job (thanks for the link) is doing: [ -x /usr/lib/php/sessionclean ] && /usr/lib/php/sessionclean So "sessionclean" looks like a PHP program that probably does use the settings. I didn't realise that the cron job wasn't part of, or maintained by the PHP team. I do think that there is a gap in the documentation somewhere since I thought I was installing a "proper" PHP but in fact it appears that I am getting something that has been tampered with. Given that the Ubuntu folk have tampered with the PHP setup they should probably "tamper" with the documentation to make it match the changes they have made. I'm happy for this to be closed and I will re-raise it on Ubuntu. ------------------------------------------------------------------------ [2018-05-23 13:16:31] spam2 at rhsoft dot net no the cronjob does not use the settings "There is no mention of the cron job here so if there is a cron job and it is using this value then the documentation needs updating" - nonsense - distribution specific modifications don't belong to the php documentation at all it's your repsonsibility to read your distributions manpages https://serverfault.com/questions/511609/why-does-debian-clean-php-sessions-with-a-cron-job-instead-of-using-phps-built ------------------------------------------------------------------------ [2018-05-23 13:07:04] Alastair dot Growcott at dynautics dot com Does the cron job use the gc_maxlifetime value in the php.ini file? The documentation says: ----- session.gc_maxlifetime integer session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor). Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path. ----- There is no mention of the cron job here so if there is a cron job and it is using this value then the documentation needs updating. Also I don't see any sign of any cron job. What user/crontable will it be running under? ------------------------------------------------------------------------ [2018-05-23 10:01:39] cmb@php.net > Ubuntu is Debian based and likely also uses a Cronjob by default It looks like this is the case here, isn't it? ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=76368 -- Edit this bug report at https://bugs.php.net/bug.php?id=76368&edit=1

« previous php.bugs (#246440) next »