php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #14798 session.gc_maxlifetime does not work (Reopen Bug ID #3793)
Submitted: 2002-01-02 08:37 UTC Modified: 2002-08-16 21:33 UTC
Votes:13
Avg. Score:4.2 ± 1.4
Reproduced:10 of 12 (83.3%)
Same Version:6 (60.0%)
Same OS:8 (80.0%)
From: bs_php at infeer dot com Assigned:
Status: Closed Package: Documentation problem
PHP Version: 4.1.1 OS: Windows ONLY
Private report: No CVE-ID: None
 [2002-01-02 08:37 UTC] bs_php at infeer dot com
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* ?!
                         ---
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)

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.). .

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."


[Session]
session.gc_probability = 100
session.gc_maxlifetime = 60
session.save_handler = files
session.save_path = c:\tmp\
session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /
session.cookie_domain =
session.serialize_handler = php
session.referer_check =
session.entropy_length = 0
session.entropy_file =
;session.entropy_length = 16
;session.entropy_file = /dev/urandom
session.cache_limiter = nocache
session.cache_expire = 180
session.use_trans_sid = 1

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-01-06 20:14 UTC] yohgaki@php.net
Any windows users can confirm this?

BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC.
 [2002-01-08 06:22 UTC] bs_php at infeer dot com
> Any windows users can confirm this?
What you mean by *any*? At least 3 users working with WIN 2k (Me, kori_mail@hotmail.com, jmoore@php.net) 2 of them using FAT32. (See bug report #3793) 

> BTW, gc_maxlifetime is in sec. and *explained* explicitly in php.ini IIRC.
I read tfm! Read line 2 of my report above:
"session.gc_maxlifetime *documented* as a lifetime measured in seconds ... "
OK,OK if you say it's secs I'll believe you. I can't verify it because of the current bug. They're indications that the doc could have been wrong (Read my report above)

 [2002-01-11 18:43 UTC] yohgaki@php.net
Clarify:
It sounds like problem is in filesystem used. Are you sure your FAT FS supports mtime? i.e. modified time? If you created the partition with old FAT FS. mtime is not supported and it will not work.

Since you are using W2K, could you use NTFS, if not?

BTW, I don't use W2K now, but files save handler worked for me with PHP 4.0.x. 
 [2002-01-13 16:01 UTC] bs_php at infeer dot com
I'm using FAT32 and mtime is working fine! I use mtime in 2 PHP objects I've wrote (a cache system and a extention to PHP's session handling) and mtime is fine! 

Again: jmoore@php.net and I suspect the bug in *atime*!!! 

NOTE: Fat32 on Win has following effect as described by hurtado@arrakis.es under the user comment of fileatime() http://www.php.net/manual/en/function.fileatime.php:
"Windows *does* track file access times, however it seems (that FAT32) only keep track of the date a file was last accessed, ignoring the actual time, so if you try to pull the fileatime() for a file in Windows, you will get 00:00:00. You can verify this by right-clicking on any file in Windows explorer and viewing the properties of the file."

If atime is beeing uses then this would explain way all session data is looked as garbage after 00:24. There must be a fallback *without* the use of atime because "Some Unix filesystems can be mounted with atime updates disabled to increase the performance." and because of the Win FAT32 problem. 

> Since you are using W2K, could you use NTFS, if not?
I can't and don't want to switch to NTFS for several reasons:
a) Even if it would work, you can't go and tell ppl to go and change the filesystem!
b) I have a dual boot system and depend on the FAT32.

 [2002-01-13 16:22 UTC] yohgaki@php.net
Ok, I'll assume your FAT FS supports mtime.
However, I still have to ask you if it work with NTFS. I don't use Windows now .

If there is a problem, I think problem is in TSRM code ;)
 [2002-01-13 17:03 UTC] bs_php at infeer dot com
OK, as I thought: The test (see top entry) works on Win with NTFS.
What I did:
 a) I set session.gc_probability = 100
 b) I mad a little FAT32 partition on F: and a NTFS partition G:

The bug *only appears* when using FAT32: 
   session.save_path = F:\tmp

Session works fine when using NTFS:
   session.save_path = G:\tmp

So it MUST be a *atime* related problem. 
 [2002-01-13 20:30 UTC] yohgaki@php.net
Under Windows, session save path's directory is FAT FS and save handler is files, gc call is deleting all session files. 

Status = Analyzed.

(I cannot fix this one, since it's windows specific :)
 [2002-01-21 17:34 UTC] kori at volny dot cz
Hi, I tested PHP 4.1.0 (release) on Windows XP Professional and there is my report:

WWW server: IIS 5.1
Filesystem: NTSF (Compressed)

PHP.INI:

[Session]
session.save_handler      = files   ; handler used to store/retrieve data
session.save_path         = C:/Windows/Temp    ; argument passed to save_handler
                                    ; in the case of files, this is the
                                    ; path where data files are stored
session.use_cookies       = 0       ; whether to use cookies
session.name              = PHPSESSID  
                                    ; name of the session
                                    ; is used as cookie name
session.auto_start        = 0       ; initialize session on request startup
session.cookie_lifetime   = 0       ; lifetime in seconds of cookie
                                    ; or if 0, until browser is restarted
session.cookie_path       = /       ; the path the cookie is valid for
session.cookie_domain     =         ; the domain the cookie is valid for
session.serialize_handler = php     ; handler used to serialize data
                                    ; php is the standard serializer of PHP
session.gc_probability    = 100       ; percentual probability that the 
                                    ; 'garbage collection' process is started
                                    ; on every session initialization
session.gc_maxlifetime    = 600    ; after this number of seconds, stored
                                    ; data will be seen as 'garbage' and
                                    ; cleaned up by the gc process
session.referer_check     =         ; check HTTP Referer to invalidate 
                                    ; externally stored URLs containing ids
session.entropy_length    = 0       ; how many bytes to read from the file
session.entropy_file      =         ; specified here to create the session id
; session.entropy_length    = 16
; session.entropy_file      = /dev/urandom
session.cache_limiter     = nocache ; set to {nocache,private,public} to
                                    ; determine HTTP caching aspects
session.cache_expire      = 180     ; document expires after n minutes
session.use_trans_sid     = 0       ; use transient sid support if enabled
                                    ; by compiling with --enable-trans-sid
url_rewriter.tags         = "a=href,area=href,frame=src,input=src,form=fakeentry"

------------------------------------

1) The ISAPI module doesn't work right (there is some data output error) with ISS 5.1.
   CGI version works fine.
   
2) There is still the same problem with "session.gc_maxlifetime".

3) "session.gc_probability = 100" - there is one change. It deleted all files except last accessed session file in previous versions of PHP, now It do nothing (NO files, including expired files are deleted).
   
4) Session_destroy() function works fine.


I will test CGI & ISAPI modules with W2K professional (Apache, IIS 5.0) on FAT32 filesystem tomorrow.

-- Kori
 [2002-01-22 03:44 UTC] kori at volny dot cz
OS: W2K Professional (SP2)
WWW: Apache, IIS 5.0
Filesystem: FAT32

1) ISAPI module works fine with IIS 5.0. Is some bug in IIS 5.1?

2) There are same problems as I reported before with "session.gc_maxlifetime".
     
3) "session.gc_probability  = 100" on FAT32 deletes other session files except last accessed/created session file as before.  

-- Kori
 [2002-01-23 05:35 UTC] yohgaki@php.net
This is data loss issue. Mark it as Critical.
 [2002-01-23 06:00 UTC] yohgaki@php.net
Could you try see if it helps?

session.save_path = C:\tmp\path\for\session\data

If save path is deep enough, session module will not delete data files.
You should be able to workaround this problem with deep save path.
(And you can delete too old session data files with batch job)


 [2002-02-09 15:38 UTC] adnev at podvdonik dot cz
I don't know if the problem is related to mtime or atime or what else but on win2k+fat32, there are three pieces of information about file times:

- creation time: precision=seconds
- last modification time: precision=seconds
- last access time: precision=days

As you see the last access time is somehow special. If you want to get this time in seconds it will return the time corresponding to midnight of that day.

A problem that can not be solved:

The file last modified time is updated only if the file is written. This happens only when some session data is modified. A web client can surf on a site during 1 hour without modifying any session data. So logicaly, using the garbage collector with a maxlifetime less than 2 days (on a win+fat platform) will result in data losses.

And test reports: I have tested the following:
.maxlifetime=3700
.probability=100

- set the time to midnight + 2 minutes
- create 1 session file
- create a second session file thanks to another client of my website
=> the first session file was deleted

- browse the site with one client only (=1 session file)
=> the file name was modified on every access that means that the file was deleted on a session_start call and a new created on the script termination (implicit call to session_stop)

May this help you to improve the garbage collection feature.
 [2002-02-26 03:14 UTC] zhaoxd at capitel dot com dot cn
My Operating System is Linux,and I found the same error.
session.gc_maxlifetime = 60
It's doesn't work
 [2002-02-26 06:37 UTC] yohgaki@php.net
Please do _NOT_ add comment if you are using other than Windows.
 [2002-07-02 10:50 UTC] chlabicz at plusnet dot pl
The bug almost killed me.

>[23 Jan 6:00am] yohgaki@php.net 
>Could you try see if it helps?
>session.save_path = C:\tmp\path\for\session\data
>.....
But wouldn't the
session.gc_probability = 0
do the same (for me it seems to work fine).
 [2002-08-16 21:02 UTC] rasmus@php.net
I really don't see anybody with any interest in writing code to make this work on FAT filesystems.  Don't run web servers on crap filesystems.  If you do, write your own session handler.  Same goes for filesystems where file modification timestamps are ignored.  Write your own session handler and manage the garbage collection yourself.  We'll need to document this, of course, so marking this as a documentation problem.
 [2002-08-16 21:33 UTC] rasmus@php.net
The fact that the filebased session handler needs a filesystem with atime support has now been documented.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 19:01:33 2024 UTC