php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #76368 Garbage collection configuration not handled correctly.
Submitted: 2018-05-23 06:53 UTC Modified: 2018-05-23 13:31 UTC
From: Alastair dot Growcott at dynautics dot com Assigned:
Status: Not a bug Package: Session related
PHP Version: 7.0.30 OS: Ubuntu
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: Alastair dot Growcott at dynautics dot com
New email:
PHP Version: OS:

 

 [2018-05-23 06:53 UTC] Alastair dot Growcott at dynautics dot com 
Description:
------------
The exact version is PHP 7.0.30-0ubuntu0.16.04.1 and is running in a Docker container for a website. I got the version running the CLI command though.

My settings are:

session.gc_probability = 0
session.gc_divisor = 1000
session.gc_maxlifetime = 1440

As I understand the documentation, having a probability of 0 means that garbage collection should never happen. However I am finding my session is losing all its values after about 30 minutes (I have never measured it exactly). I increased the gc_maxlifetime value to 144000 and after 5 hours the session was still in existance.

This started happening after a recent rebuild of my Docker container when I moved from one server to another. It looks as if the meaning of a gc_probability value of zero has been changed from "never" to "always".


Test script:
---------------
I haven't tested it, but this should reproduce the problem:

<?php

    session_name("Demonstration");
    $result = session_start(['cookie_lifetime' => 86400]);

    if (!$result) {
        echo "Failed to start session.";
    } else if (isset($_SESSION['test_value'])) {
        echo "Bug didn't happen.";
    } else {
        echo "Starting new session."
    }

?>


Create a website with this script and the settings above. Load the page. Wait about 30 minutes. Load the page again. You can shorten the wait by reducing session.gc_maxlifetime in the configuration.


Expected result:
----------------
On the first load you should see "Starting new session.". On the second load after some time you should see "Bug didn't happen.".

Actual result:
--------------
Instead of "Bug didn't happen." you will see "Starting new session." as the session has been garbage collected.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-05-23 07:49 UTC] spam2 at rhsoft dot net 
Ubuntu is Debian based and likely also uses a Cronjob by default as any smart setup - under load its not funny have the burden of deal with thousands of files in the webserver with likely collisions that more than one worker triggers the cleanup
 [2018-05-23 10:01 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2018-05-23 10:01 UTC] 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?
 [2018-05-23 13:07 UTC] Alastair dot Growcott at dynautics dot com
-Status: Feedback +Status: Assigned
 [2018-05-23 13:07 UTC] 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 13:16 UTC] 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:29 UTC] 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:31 UTC] requinix@php.net
-Status: Assigned +Status: Not a bug -Assigned To: cmb +Assigned To:
 [2018-05-23 13:31 UTC] 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.
 [2024-02-12 01:31 UTC] nanocaiordo at gmail dot com 
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.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Nov 09 05:00:02 2025 UTC