Timeline for Session is lost after some time around 25 minutes
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 13, 2017 at 14:10 | comment | added | ishegg | Well, that might be a starting point for your debugging process. What's different between the two? Hardware, software, settings, etc? (obviously, relevant to sessions). | |
| Sep 13, 2017 at 14:09 | comment | added | Shaonline | Looks like it is the only way to go, but I still haven't figured out the reason. I am saying this because the same code is in two different environments. I am getting this session problem on one only, where php.ini values for session.gc_maxlifetime is 1440 on both environments. | |
| Sep 13, 2017 at 13:58 | comment | added | ishegg |
A (bit) "hacky" workaround of what @OptimusCrime said, is setting the session.save_path to another directory so the cronjob can't get to it, with session_save_path(). This is of course less than ideal. Is it at all possible for you to change the values directly in the ini file?
|
|
| Sep 13, 2017 at 13:37 | comment | added | OptimusCrime | @Shaonline If you have a debian based system, the garbage collection is done with a cronjob that fires every minute or so. This script (and similar utility scripts) will run with the default php.ini values. ishegg is correct, you should set this setting in the main php.ini file, NOT a script in user land. | |
| Sep 13, 2017 at 13:36 | comment | added | Shaonline | the ini_set() assignments are used on every page actually. Shouldn't this keep this new value if it is on every page? | |
| Sep 13, 2017 at 13:30 | history | answered | ishegg | CC BY-SA 3.0 |