Re: Bug #14798: session.gc_maxlifetime does not work (Reopen Bug ID #3793)

Bs Php wrote:

From:             bs_php@infeer.com

Operating system: Win 2k

PHP version:      4.1.0
PHP Bug Type:     Session related

Bug description: session.gc_maxlifetime does not work (Reopen Bug ID #3793) Befor going into the bug-report an importent question: session.gc_maxlifetime documented as a lifetime messured in *seconds* with default = 1440

               1440s = 24min. hmm.... 24min ?? Expectiong the gc_maxlifetime to be rather long 24 min. seams a short time

AND 24 relates more to 24h! So is it realy *seconds* ?!

                         ---

It's in sec. and explained in php.ini-recommended and php.ini-dist :) If session life time is too long, bad users will easily perform DoS attack, also.

The Bug: As reported in Bug ID #3793 (from kori_mail@hotmail.com) following still happens (taken from sniper@php.net, 2000-12-07 and veryfied by mfischer@php.net, 2001-11-25): 1) "session.gc_maxlifetime" does not work - I set this to 60 sec, but I can read values from the session even when time expired. (I start the session and then I wait more than 60 sec before calling other script)

That's true. I might add the same feature as I did in pgsql session save handler. This breaks some sites for sure. We need discussion for this.

2) When I set "session.gc_probability = 100" in php.ini, ALL other session files are deleted (only one session can be used at the time - if 2 clients are connected to server, the second client deletes session of the first client, etc.). .

Hmm. I don't use files handler/Windows. Is this true for UNIX like OS, also?

My Comment: To (1): This may be intended when using cookies! Because if session.cookie_lifetime is =0 (until browser is restarted) finding a valid SID in the cookie may prevent the gc from destroying the session data. (The doc leves this open). To (2): For testing I've set "session.gc_probability = 50" but the effect is the same. As soon as the gc runs, all other session-files are deleted. gc_maxlifetime has no influance. jmoore@php.net wrote that it may have to do with 'atime' and I would think so too. I would consider to use 'mtime' (maybe as fallback). Even the PHP-manual makes restriktions to 'atime': "Some Unix filesystems can be mounted with atime updates disabled to increase the performance."

I think mtime should be used instead of atime. Moving GC to RSHUTDOWN will fix your problem :) if we come up with agreement on this, it may be changed. -- Yasuo Ohgaki