Apologies, probably this is not the right place to ask this question but I need this solved. The main thing that connects to here is that I use comfort update for something like 10 years and it works. I run surveys mainly for my colleagues and sometimes patients, these are usually fairly small surveys in size and numbers of responses. I am running into difficulties that prevent people from submitting their responses and that is not good at all:
 
The worst problem is I do not know how to control this behaviour and I cannot find a clear up-to date description. Is there a setting in the config file for LS, is there one for a Yii framework where is this set? Does it depend on database table session (and how it is different from another session type?)? Or does it depend on server php config file. How to diagnose this problem, exactly? 
 The baseline is - my colleagues are busy and it easily could happen that they start writing their answer in the morning and then something happens that takes them from completing the survey till the end of the working day. Or they get distracted from survey for a couple of hours. And they come back and see the above screen on submission. That is a big deal, I am sorry to say. I need to know how to prevent or control this behaviour. For my use case (and I would imagine for many these days) it would be perfectly acceptable that survey expired in 24 hours. It is there on a browser tab, keeping many tabs open is a customary thing these days. How can I make sure I can control LS session expiry time?
Many thanks for your help and advice, which I dearly hope is coming,
Limesurvey base directory contains php.ini which has:  
LS: LimeSurvey Community Edition Version 6.6.6+241002

And for the other settings ?
You have a lot of disk size for session ?

You can put a session.gc-probability  to 0 too. www.php.net/manual/en/session.configurat...ssion.gc-probability


Else : you can try gitlab.com/SondagesPro/coreAndTools/HeartBeat

Thanks Denis,

What I would really like is to know all the variables that can cause this error and how to control them. Disk space on the server is not an issue. The problem seems to be that there are several such variables that are possibly stored in different places.

If I know what to do, I do not mind at all to write the process up so it is available to others. I am ok with working out complexity, but my current impression is that the whole thing may be quite muddled. I hope to be wrong.

In general, sessions are usually handled by the server, not by Limesurvey itself. That is why it is difficult to say: THIS is the problem.

And yes, depending on your server setup, there might be different areas / settings that might impact this.

How and where is this hosted?

That's very helpful. It is A2 hosting with cPanel. Under cPanel there is PHP version selector (I have chosen 7.4) and with that there are options that I can influence (session.gc_maxlifetime being the one I should probably change first): Where else could be the parameters that could influence session timeout?
Apparently php.ini from LS directory has been overriden then? 
Any other places where this could be influenced, or this should be it?
Many thanks.
R

Looking at this your session max. lifetime is 1440 seconds, not 28800 seconds as you originally mentioned.

This difference is significant. 1440 seconds is 24 Minutes, while 28.800 seconds are 490 minutes or 8 hours.

So I would start there. If your surveys are short, even 1440 seconds should be enough, because the session time should renew with any new action on the survey (aka clicking the next button). So even if a respondent has to think a couple of minutes, 24 Minutes should be enough. Now if they get up, leave for a while and then come back, then 24 Minutes might not be enough.

One other thing that could be happening is some kind of cron script emptying the session folder more frequently.


stackoverflow.com/questions/14703363/why...minutes-1440-seconds

Thanks, I appreciate that and now I am testing with 86400 which should give me 24 hours. What confused me was that there was php.ini in the limesurvey root directory. That is where I entered the value of 28800 and clearly that one was not respected. I hope the change I now made via cPanel interface will work. You mentioned cron and session folder. Where that session folder should be?

Where the session folder for installation is depends on your installation. So again, this is more web server administration related than Limesurvey related. Probably the support forums at your hosting company (or for Cpanel) are the better contacts.

How did you install Limesurvey on your server? Because there should be no php.ini in the limesurvey folder. At least it doesn't come with Limesurvey.

At least I don't see any here:
github.com/LimeSurvey/LimeSurvey

So these configurations should be done via your Cpanel interface.

I highly doubt it, that this is your case, depending on who has access to your installation. But I have already heard of people who "clean" the session folder via their own script, triggered via cron jobs. But if you are the admin (and always have been) and you did not set up such a script, you should be safe.

Now I don't know the folks at A2 Hosting and how they are working. That is a totally different beast.

My apologies,
Same problem even after setting the parameter session.gc_maxlifetime = 86400 via cPanel.
However I have read more and the session expiry problem has been around for quite a while. For example the issue in 2018 in these forums we read:

" version 3.17.1, and had the same "session expired" problem, plus other strange symptoms such as a login impossibility, and I finally solved it.

It turned out to be a cookie problem. By default, limesurvey uses the classical "PHPSESSID" cookie name to store the session info. "

The point is that the error thrown is by Limesurvey; it could be timeout problem or a different bug. In Limesurvey documentation I do not see it clearly documented as to what kind of session it is and where the potential culprits could be. It is unfortunate and interferes with usefulness of LS. How convincing can you be if your users report that they cannot submit responses (but they are never complaining about this if they use Microsoft Forms). So introducing LS to organisations is more difficult if I cannot show this can work reliably.

I sure can go to A2 admins and ask them to change some php parameters, but I would feel much more confident if I knew in detail about the session mechanism that is affected and what avenues one can explore about this. Given that sometimes in LS forums this is referred to as "the infamous session expired problem" it is a bit frustrating that there is still little clarity as to how this problem arises. For example in LS manual the paragraph on this error only mentions suhosin (which my installation very likely is not using). understanding the session mechanism would give a better idea how to approach hosting admins with this repetitive problem. Presence of such information would save time for quite a lot of people when troubleshooting and thus would also be helpful in being able to recommend using LS to others.

The problem is that these are generally very specific cases and mostly related to specific setups / installations.

As we do not have any access to your setup, we also can't trouble shoot.

Bugs/issues from 2018 and LS 3 will hardly have any relevance for LS 6, as this is basically a complete rewrite. But if you want us to have a look at a 6 year old thread, please post the link rather just a text and make it easier for us to find it.

Now, there is only so much we can do to help here in the forum, when it comes to this type of error / problem, as we can't really reproduce it and also haven't seen any of those issues in the forum lately for LS 6.

We are trying to help here (in our free time), but there are certain things that are difficult to trouble shoot, if we can't reproduce them.

Regarding sessions, something that can be problematic is when tow different web applications (e.g. Limesurvey and some other tool) are installed under the same URL. The different sessions might interfere with each other. So are you running other web applications on the same account?

Depending on the hosting environment, these applications might use the same resources and interfere with each other. This could be another issue that I can imagine.

Thanks Holch,

Not a problem. For now I take it it must be the php session specific problem and as such I will try discuss that with A2 tech support. I run a couple of static websites alongside (under different sub-domains though), there is nothing php related, so I do not imagine this could interfere. Of course, I have phpMyadmin access, but I doubt that should interfere.

I run a couple of static websites alongside (under different sub-domains though), there is nothing php related, so I do not imagine this could interfere.

Agreed. Static websites should not interfere. Also, usually different subdomains different "accounts" on most platforms (I assume this is the case for Cpanel as well) and thus should not interfere either. I just thought I'd mention it.

Of course, I have phpMyadmin access, but I doubt that should interfere.

phpMyAdmin shouldn't interfere either. Highly doubt it.