PHP session vars time out after only a few minutes.

[Spork52]

I have a PHP site on a shared host (PHP version: 5.3.3-7.1+hw2). The session variables (e.g.: $_SESSION["some_variable"]) usually time out too fast (under 5 minutes). On the local test server (PHP 5.4.10) there is no problem.

The hosting tech support guys are no help.

phphinfo (below) shows session.gc_maxlifetime set for 24 minutes. So why are the sessions being cut short?

Also, there are empty folders called /tmp/php-ses and /web/tmp/php-ses. What are those for?

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

phpinfo says:

session.auto_start Off Off
session.bug_compat_42 Off Off
session.bug_compat_warn Off Off
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure Off Off
session.entropy_file no value no value
session.entropy_length 0 0
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 0 0
session.hash_bits_per_character 5 5
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path /var/lib/php5 /var/lib/php5
session.serialize_handler php php
session.use_cookies On On
session.use_only_cookies On On
session.use_trans_sid 0 0

 

[jpadie]

there are some oddities in your php.ini; and I'm surprised some of them are not throwing errors. have you got error reporting and error display turned on in php? always a good first step.

you don't say what OS you are using, nor what version of php. So I'm going with a linux based OS and php >=5.2

first steps in debugging:

1. change the session_gc_probability to 1 (for local and master). I have no idea what having this on 0 might lead to. as the calculation is session.gc_probability/session.gc_divisor resolves to 0/1000 = 0 it should mean that session garbage collection (deletion of session files) never occurs. but equally php may be complaining. On ubuntu this is the default (or was for some versions) and instead ubuntu had an automatic cron job that ran every hour and swept the directories. So if you are running ubuntu or a derivative version and you do change the probability, then you should disable the culprit cron job. In any event, good to check the cron job as it may be that it is running every minute at the moment. or is stuck...

2. also your session_save_path directive has not been set. you should point this to a directory that has read/write permissions for the user under whose credentials php is running. make sure the directory/folder exists of course. You can make this change at runtime, but I'd advise doing it in php.ini. Or if you are running a virtual host based system you may prefer to set this in a site-specific httpd file or htaccess. note that the format for doing so is not the same as php.ini.

after any change to php.ini (or an httpd config file) you should reboot the server or at least stop/start the web-server.

note that if you are testing session functions on localhost or even on the same subnet you run the risk of having race conditions caused by disks being slow to complete the write operation on the session store. extfs is particularly slow and bad at having folders full of small session directories. so, for example, if you hit refresh after a page load php will immediately open the session store and at that point the data from the previous script execution may not have finished writing. This is difficult to prevent, but what often helps is:

1. when debugging, try to have your session activities early on in your script and the explicitly close the session (session_write_end()) as soon as you can.
2. don't hit refresh too quickly.... wait a few seconds first.
3. on extfs systems - either create a partition with another filesystem (reiserfs or whatever) and point your session store at that, or create a bunch of numbered sub-directories and use the N format to have php spread the files around. there is a batch file bundled with php that will create the folders for you. I think it is in /ext/session (of the php distro) and is called mod_files.sh

in an internet environment this is unlikely ever to be an issue as latency will nearly always be a greater factor than disk speed. However if it does become an issue (and it may do for older servers and faster networks) then physical solutions might involve storing the session on an SSD or migrating to a database storage system for the sessions. The latter is useful if you have a server farm behind a squid server but want to maintain sessions (which of course you would). either a single database is addressed by each web-server or a master-slave replication environment is created. or a cluster db. Whichever way, the performance is supposed to be better than file based replication or network access to the session store. I have not done any comparisons myself.

 

[Spork52]

Thank you for the extensive reply (I learned a lot), but I think you read my post so quickly that you didn't notice:
[ul]
[li]The site is on a shared host (so I can't do some of the stuff you mention)[/li]
[li]The PHP version is 5.3.3-7.1+hw2 (what is hw2?)[/li]
[li]session_save_path is indeed set (/var/lib/php5)[/li]
[/ul]

I added error_reporting(E_ALL) to the top of all pages to turn on debugging (is that the correct way?), but it had no effect, which seems strange--there must be some uninitialized variables floating around in my code.

I noticed that late at night the timeouts don't occur so fast. Then I read this in the PHP documentation:

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

Could the host have set the server up to use a shared location for the session data? I don't see /var/lib/php5 when I FTP to the site.

Is it okay to set session_save_path to the /temp/php-ses folder that I mentioned in my first post?

 

[jpadie]

sorry - i missed the reference to php version
the difference between 5.3 and later will not be the cause.

The site is on a shared host (so I can't do some of the stuff you mention)

it would be very very unusual that you cannot influence your php setup on any server. if you truly cannot then leave the host immediately.

session_save_path - sorry - completely missed that. not enough coffee. that is a most odd place to store session files though. does it exist? is that folder readable and writable by the php user?

I don't see /var/lib/php5 when I FTP to the site.

ftp is useless for sensible server access. Use ssh and ensure you have root permissions. If you are truly operating in a shared environment (rather than virtualised) i suggest looking for an alternative host over which you have more control. rackspace offer good solutions and aws is free at certain levels for an amount of time.

but yes - it is entirely possible that the host has specified a different location to which neither you nor anyone else can access over ftp. but of course the php user should be able to do so and MUST be able to do so for session read and write.

without knowing how your shared server is set up it is difficult to answer your specific question with anything other than 'possibly'. But you should still be able to influence your set up and set your own session paths etc by uploading a php.ini to the root of your web server. try it with just one altered setting and then run phpinfo(). hopefully it should reflect the new php.ini. If not you have to talk with your host (if you know that your code is correct - you have not posted that) or better still move to a server over which you have your own control.