Hi Leigh,
On Sat, Jan 31, 2015 at 8:24 PM, Leigh <lei...@gmail.com> wrote:
> On 31 January 2015 at 11:12, Bas van Beek <b...@tobin.nl> wrote:
> >
> > Well the number 1440 itself is not so arbitrary as it's the amount of
> minutes in a day. Maybe that's why the number popped up.
> >
> > In the end 24 minutes does seem to be fine for the majority of people
> and with people that care about session duration it's really easy to update
> :)
> >
>
> I like the idea of this being a 15+ year old "bug" where minutes were
> used instead of seconds :)
session.cache_expire? It's minutes. Do you mean session.cache_expire should
be seconds?
session.gc_maxlifetime is second.
files/mm take it as seconds.
mod_files.c - master
295 /* check whether its last access was more than
maxlifet ago */
296 if (VCWD_STAT(buf, &sbuf) == 0 &&
297 (now - sbuf.st_mtime) > maxlifetime) {
298 VCWD_UNLINK(buf);
299 nrdels++;
mod_mm.c - master
458 limit -= maxlifetime;
459
460 mm_lock(data->mm, MM_LOCK_RW);
461
462 ehash = data->hash + data->hash_max + 1;
463 for (ohash = data->hash; ohash < ehash; ohash++) {
464 for (sd = *ohash; sd; sd = next) {
465 next = sd->next;
466 if (sd->ctime < limit) {
467 ps_mm_debug(("purging %s\n", sd->key));
468 ps_sd_destroy(data, sd);
469 (*nrdels)++;
470 }
471 }
472 }
Current session module does not keeping last update time and relayed on
probability based GC solely. gc_maxlifetime value does not have precise
meaning.
I proposed precise session data deletion in other thread. The same can be
done for precise session data expiration.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
