Our installation of LimeSurvey works flawlessly for weeks on end, but then, for some unknown reason, every session begins to immediately time out. The admin will sign in, the page is brought up, but when going to a new page, they are immediately required to log in again.

Users are unable to start a survey, and instead are presented with the error saying their session expired.

However, if I reboot the server, it will work fine for awhile - depending on the nuber of users taking the survey.

The sessions are set to store in files in the /tmp folder.

session.auto_start is set off
session.gc_maxlifetime is set to 1440

The complete list.

session.auto_start Off
session.cache_expire 180
session.cache_limiter nocache
session.cookie_domain no value
session.cookie_httponly Off
session.cookie_lifetime 0
session.cookie_path /
session.cookie_secure Off
session.entropy_file /dev/urandom
session.entropy_length 32
session.gc_divisor 1000
session.gc_maxlifetime 1440
session.gc_probability 1
session.hash_bits_per_character 6
session.hash_function 0
session.name PHPSESSID
session.referer_check no value
session.save_handler files
session.save_path /tmp
session.serialize_handler php
session.upload_progress.cleanup On
session.upload_progress.enabled On
session.upload_progress.freq 1%
session.upload_progress.min_freq 1
session.upload_progress.name PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix upload_progress_
session.use_cookies On
session.use_only_cookies On
session.use_strict_mode Off
session.use_trans_sid 0
SimpleXML


I don't believe this is a LimeSurvey issue in and of itself, but some sort of server setting, but can't find anything dealing with this particular issue. I'm running php 5.6.31, though this has occurred on 5.5

And insight or thoughts would be greatly appreciated.

Thanks

Workaround : use DB session ?

But sometimes it's better to set session.gc_probability to 0 and use a cron job for the garbage.

RLaRock wrote: However, if I reboot the server, it will work fine for awhile - depending on the nuber of users taking the survey.The sessions are set to store in files in the /tmp folder.

Check the free space for every partition. Is there enough space? Or is the tmp folder on a tmpfs ramdisk, which is running out of space till you restart the server.

Create a folder for phpsessionfiles (e.g. /tmpphp) and don't use the /tmp for sessions.
Perhaps other applications are deleting files in the /tmp folder.

What OS/Distribution is used?

Thanks for the responses.

The session issue occurred again today, and I took the first suggestion of switching to database sessions instead of file based session storage.

That seems to have worked.


What I did notice in doing so is that the active sessions are rather large - averaging around 2.2 Mb each, which I hadn't realized. So Jelo's question about the /tmp folder running over its allocated size seems most likely. The issue always seems to occur around the same session number - between 80-90.

Rebooting deleted all the sessions in /tmp, so it would have corrected the storage issue.

At this point I will stay with the database storage for the duration of this current active survey and then look at setting up a separate folder.

Thanks, for the help!

RLaRock wrote: What I did notice in doing so is that the active sessions are rather large - averaging around 2.2 Mb each, which I hadn't realized.

The sessionfilesize is quite insane. 1-2 MB from the start. So when you got rush time the sessions are occupying large amounts of space. The typical setups with restricted tmp folder and php file sessions pointing to /tmp are not suitable for LimeSurvey. So you're not alone. On a single instance with SSD I/O I consider filebased sessions files quite suitable.

Someone did a few tests with Magneto and PHP-sessionhandler.
magebase.com/magento-tutorials/magento-s...h-to-choose-and-why/