Re: Re: session.gc_maxlifetime

it could be ip address changes. interesting thought. i think i should add some special logging. it's a dedicated freebsd server with one app. On 9/23/09 6:43 PM, "Ralph Deffke" <ralph_deffke@yahoo.de> wrote: > finaly we went with a custom cooky handling, however the customers > requirements where two days. > > if u are shure that the server is still the same hardware like it has been 6 > years ago then it might be some client stuff, however if there are other > applications, pages running (virtual servers) then it would still be to > consider. mamory and resource management is deep os. again I wouldn't trust > for that amount of session livetime. > > I dont think, putting it down to three hours would help much. > > and of course, it could be client side also. Can't you figure out the > clients? > and keep in mind that a lot of people connect to UMTS rigzt now, these > systems deconnect on idle lines and reconect without the users even know it. > Also a lot of lines change IP address at midnihgt. > > cheers > ralph_deffke@yahoo.de > > "Tom Worster" <fsb@thefsb.org> wrote in message > news:C6E00521.12D98%fsb@thefsb.org... >> there's a need for long timeouts in this app but could perhaps be reduced >> from 6 to 3 hours. >> >> the sessions are cookie based using php's 'file' handler and >> session.cookie_lifetime=0. the server appears to have plenty of free > memory >> and appears not to have swapped in nearly a year of uptime. load averages >> indicate a pretty quiet server. there are currently 170 kbyte total in 90 >> serialized session files which is typical and not a memory load. the >> distribution of modification times doesn't indicate heavy activity: ~20 >> files in the last 15 minutes and 35 in the last hour. >> >> so i think the os can handle this. plus the app ran for 6 years before >> anyone reported being prematurely logged off. i'm looking for other >> possibilities: odd browser behavior, network trouble, ... >> >> >> are there any browsers that have configurable cookie handling policy such >> that they time out a cookie? >> >> one web site i use displays this curious message: "For your protection, >> sessions are open for a limited period of time on our website. Please >> sign-on again. NOTE: Your browser may also limit secure connection time, > and >> automatically log you out independent of our timeout procedure." >> >> that could be referring to browsers timing out an ssl connection. or > perhaps >> the cookie? >> >> >> btw: when you said in your email you wouldn't trust a long gc_maxlifetime, >> and you would only use a cookie-based solution for long session. did you >> mean that you wouldn't trust php's cookie-based session handler? and you >> would use a custom handler instead? >> >> >> On 9/22/09 4:46 PM, "Ralph Deffke" <ralph_deffke@yahoo.de> wrote: >> >>> Hi Tom, >>> >>> in sometimes 2001 I did have incidences with those things, and as I > remember >>> over the past years there where some trouble with operating systems and >>> stuff. This part is very deep inside the os. I would expect that this is >>> still to consider. I also would check, if this occurs on very busy/low >>> memory server. >>> >>> If I would programm the garbage collection clean up part, and if the > server >>> is about to run out of memory, I would kill sessions being longer time > idle >>> even when they are not yet as old as it is set in the gc_maxlifetime. > This >>> would be far better then shutting down the whole server just because > there a >>> 100 of idle sessions waiting to get used again. >>> >>> as u mention a maxlivetime of 6h I would bet, that this is the problem. > I >>> would not trust such a long lifetime at all. >>> >>> If sessions have to be active such a long time, I would see only cooky > based >>> solutions >>> >>> let me know, what u did investigate on this. >>> >>> ralph_deffke@yahoo.de >>> >>> >>> "Tom Worster" <fsb@thefsb.org> wrote in message >>> news:C6DEAE55.12CAE%fsb@thefsb.org... >>>> thank you, Ralph! >>>> >>>> i'm going to be bold and assume that tom at punkave dot com is right >>> despite >>>> that the report was discarded. >>>> >>>> i got a complaint from a client about some users reporting being logged >>> out >>>> with rather short periods of inactivity. but session.gc_maxlifetime is > set >>>> to 6 hours so i don't think that's the source of the problem. >>>> >>>> >>>> On 9/22/09 4:17 PM, "Ralph Deffke" <ralph_deffke@yahoo.de> wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> i did find this in the bug reports, its pretty new and should be an >>> answer. >>>>> >>>>> http://news.php.net/php.doc.bugs/2653 >>>>> >>>>> ralph_deffke@yahoo.de >>>>> >>>>> >>>>> "Tom Worster" <fsb@thefsb.org> wrote in message >>>>> news:C6DE9EEE.12C8D%fsb@thefsb.org... >>>>>> i'm not 100% sure what the manual means when it says... >>>>>> >>>>>> session.gc_maxlifetime integer >>>>>> session.gc_maxlifetime specifies the number of seconds after which > data >>>>> will >>>>>> be seen as 'garbage' and cleaned up. Garbage collection occurs >>>>>> during >>>>>> session start. >>>>>> >>>>>> what event exactly does the "after which" here refer to? >>>>>> >>>>>> i'd like to think that it means that a session is eligible for gc no >>>>> sooner >>>>>> than session.gc_maxlifetime seconds after the most recent access > (read >>> or >>>>>> write) to that session. but it seems dangerously presumptuous to > assume >>>>> that >>>>>> this is the case. >>>>>> >>>>>> what do you take it to mean? >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >