Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

ini_set 'session.gc_maxlifetime' for 1 day

Tags:

php

session

If I do:

ini_set('session.gc_maxlifetime', 86400);

Does this mean the user can leave there browser on the same page (inactive) for up to 1 day without the worry of the session being garbage collected and them being logged out?

What happens if the server configuration doesn't support this? (Will it give me an error? or just fail silently?)

The default garbage collection time is 24 minutes which could happen in my system easily.

Does garbage collection run on session_start?

like image 464
Chris Muench Avatar asked Jun 21 '14 01:06

Chris Muench


1 Answers

With questions like yours I tend to direct to the PHP manual page that exists for each ini setting as well: http://php.net/session.gc_maxlifetime :

session.gc_maxlifetime integer

session.gc_maxlifetime specifies the number of seconds after which data will be seen as 'garbage' and potentially cleaned up. Garbage collection may occur during session start (depending on session.gc_probability and session.gc_divisor).

  • Note: If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

  • Note: If you are using the default file-based session handler, your filesystem must keep track of access times (atime). Windows FAT does not so you will have to come up with another way to handle garbage collecting your session if you are stuck with a FAT filesystem or any other filesystem where atime tracking is not available. Since PHP 4.2.3 it has used mtime (modified date) instead of atime. So, you won't have problems with filesystems where atime tracking is not available.

To map that on your various questions:

  • Does this mean the user can leave there browser on the same page (inactive) for up to 1 day without the worry of the session being garbage collected and them being logged out?

It only means that the session is not garbage collected. If the user looses the session Id due to some other reason (e.g. the cookie gets lost or some other session ID carrying parameter), the user will seem herself as being logged out regardless of whether the session has been garbage collected or not.

  • What happens if the server configuration doesn't support this? (Will it give me an error? or just fail silently?)

That is PHP configuration not server configuration. However, in case you're not using the default session directory with the default manner to place files there, it won't give you any errors and fail silently. It's the business of the server administration to take care of session data garbage collection.

In case of the standard configuration but there are not sufficient file-rights, an error is triggered.

Internally, session debugging can be enabled as well, so that you can get messages about how many session files have been deleted.

See as well this related Q&A:

  • cleanup php session files
  • Session Files Not Getting Cleaned Up
  • The default garbage collection time is 24 minutes which could happen in my system easily.

Yes, the default setting is "1440" which stands for 1440 seconds which is 24 minutes.

You can find it in the PHP source code here:

  • http://lxr.php.net/xref/PHP_5_5/ext/session/session.c#789

It's also the same value used for the suggested ini-settings that ship with PHP.

See as well this related Q&A:

  • PHP : What is the default lifetime of a session
  • Does garbage collection run on session_start?

Yes it does. You can find it at the end of the session_start implementation:

  • http://lxr.php.net/xref/PHP_5_5/ext/session/session.c#1465

So with all this information overflow, which lessons are to be learned? PHP has garbage collection for session data because if you have sessions enabled, a lot of data is going to be produced quite easily. With the standard setting for the session save dir, it can fill-up quite quickly with a tremendous amount of files. I've experienced this my own because of some flaw I had in an application where standard garbage collection didn't kicked in (I changed the session save path because the site was on a shared hoster and my own garbage collection was not properly triggered/configured), so in the end all I could do was to access that directory from shell and let find do the work which really took really long - but it worked. So manual garbage collection.

So check your garbage collection settings and also verify after a day or two, that those are working as intended.

Next to pure garbage collection, it's also sane to track the session life-time independently within your application. That works by adding session creation time and session last activity time into the session. This will allow you to regenerate session ids if you want to allow long-running sessions and even force users to re-login after a certain time-span.

Also this protects your session handling for those cases where the session has not been deleted by the garbage collector so far because the probability didn't caught it or because it's the only session available. Du to the design issue that the garbage collector kicks in after the session has started, the garbage collector can never delete the current session.

I hope this answers your questions and gives you some guidelines.

like image 147
hakre Avatar answered Oct 29 '22 07:10

hakre