Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc.

If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.

Can you send in a reproduce script that consistently exhibits this behaviour? I can't reproduce this on my local system building from CVS. With a script the devs can tell if the problem is really with the session handling or with something else.

Hi,

Here is the test case I put together:

<?php

session_start();

echo date('r');

echo '<hr />';

if (!session_is_registered('VAR')) {
    echo 'No Session Var';
    session_register('VAR');
    $VAR = 'Session var set';
} else {
    var_dump($VAR);
    echo '<hr />';
    echo session_id();
}

echo '<hr />';


// desplay environment settings
phpinfo();

?>


I would set the session in my browser and get session details (load the page twice).  I would then wait for 30+ minutes (my last case was around 1 hour).  During this period, other users are hitting the site which inits GC.

FYI, directory listing before:

$ ls -la /var/lib/php4/ | grep 3fb8f4a6e6e37ae1e378fbddbc5b4cc4
-rw-------   1 www-data www-data    27 Sep 22 14:25 sess_3fb8f4a6e6e37ae1e378fbddbc5b4cc4

And after

$ ls -la /var/lib/php4/ | grep 3fb8f4a6e6e37ae1e378fbddbc5b4cc4
nill


I also have the output of the phpinfo() before and after if you think that would be of value.

You mention that you have change session.gc_max_lifetime in an .htaccess file. Does this mean that there are other areas of your site / other virtual hosts on the same machine that also use sessions? If that's the case, it might be that the other instances are in fact performing garbage collection because they take the master value from php.ini--I don't think the session handler is capable of telling whether a particular session file was created by a given instance of the interpreter or not, and just cleans out everything it thinks has expired.

Now that makes perfect sense!  Should this be considered just a documentation issue, or should PHP file based session support add an additional feature to distinguish sessions from different hosts?  

Thanks.  Sorry for the bogus bug report.

We'll just leave it as a documentation issue. You *can* isolate the session files between different instances by simply changing (for example) the location of the session files using session.save_path in your .htaccess file, or by writing your own custom handler.

Changing status to verified.

Okay.  Thanks again!

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

"If different scripts have different values of session.gc_maxlifetime but shares 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."