ID: 34588
User updated by: michael dot caplan at htc dot ca
Reported By: michael dot caplan at htc dot ca
-Status: Feedback
+Status: Open
Bug Type: Documentation problem
Operating System: Debian
PHP Version: 4.4.0
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2005-09-23 00:24:01] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2005-09-22 23:13:54] michael dot caplan at htc dot ca
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.
------------------------------------------------------------------------
[2005-09-22 03:01:17] [EMAIL PROTECTED]
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.
------------------------------------------------------------------------
[2005-09-21 21:30:13] michael dot caplan at htc dot ca
Description:
------------
I have a rather peculiar problem with session.gc_maxlifetime local
settings not being respected under certain circumstances. In order to
ensure that sessions created for our application would have a max
lifetime longer than the default 24 minutes, we cranked
session.gc_maxlifetime in an .htaccess file to 4 hours (local value).
However, our sessions where still being clean up after 24 minutes. I
validated through phpinfo() that it was actually picking up the local
setting, which it was. I also noticed in my testing that if I reduced
the session.gc_maxlifetime local value to less than the master value,
my sessions would be cleaned up in accordance to the local value.
When we changed the master value to 4 hours, we are no longer having
our sessions cleaned up within 24 minutes. It appears that the local
value of session.gc_maxlifetime is only being respected if it is less
than that of the master value.
The noted behaviour I beleive has to do with PHP internal session
handling mechanism. I have no other oppertations touching session
content. Also, the behaviour was noted at the file system level when
another user is connecting with a different session ID resulting in
other users sessions being cleaned up. So it is not an issue of a
current user having his session invalidated through other means outside
of garbage collection.
BTW, we are using the file based session container
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=34588&edit=1
