Question 7774 in PHP Versions Question posted in
You can find a list of all versions here.

CodeIgniter 3 session lost on regenerate session id with Memcached driver only – PHP Versions

I am working on a long time running project with CodeIgniter 3 framework. For some months we have been experiencing issues with the session getting randomly lost. I have updated the framework files to the latest version (3.1.13). And it looks like that fixed the problem on the dev servers, however on production it remains. But I noticed it now happens only when the response sends a new session cookie, which happens when the session id is regenerated. When I change the $config['sess_time_to_update'], it reflects correctly to the time it takes.

The difference between the dev and prod servers is the session driver – it’s files on dev, while on production we use memcached. So I made an experiment and switched the driver to files and the session was lost no more. I also tried a setup with Redis driver and it didn’t cause issues too. So it must be something with the Memcached driver. But I don’t want to switch to another. There are no errors in the logs. I have also checked the php.ini files and memcached variables are all with their default values.

CodeIgniter v3.1.13, PHP 7.4.3, Amazon ElastiCache for Memcached

Here’s the config:

$config['sess_driver'] = 'memcached';
$config['sess_cookie_name'] = 'ci_session';
$config['sess_expiration'] = 14400;
$config['sess_save_path'] = 'host.com:11211';
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;

Any ideas where to look or what to check would be highly appreciated.

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    If you're using an AWS ElastiCache Memcached cluster, check what endpoint you're using in your config $config['sess_save_path']. One option is to use a configuration endpoint (with .cfg. in it), the other is an individual node endpoint (with .0001., .0002., etc). If you're using a configuration endpoint, make sure you have Auto Discovery enabled (requires additional installation on your server - ElastiCache cluster client for PHP). If it's not enabled, your nodes cannot be resolved properly, which causes issues like this.

    This turned out to be the case for me. I tried logging messages on session start, regenerate and destroy and with files driver the regeneration was happening, while with memcached it didn't even call any of the functions except session_start(). After some investigation I somehow decided to recheck the host and stumbled upon this guide in AWS. Turned out a second node has been added to our Memcached cluster around the time the problems started, but we have been using the configuration endpoint without having set up this Auto Discovery. I am not sure how the setup had been working at all. So I changed the $config['sess_save_path'] to the endpoint of one of the nodes instead, and the problems disappeared. Until I install and setup the needed modules and while the nodes are not changed, this solution should work.


  2. 0

    Check out this answer. Apparently, this issue might occur if you set session’s maximum expiration time to greater than memcached‘s limitation for expiry. In that post, OP had solved it by fixing the below configuration variables which you can try:

    define('SESSION_TIME_OUT', x);
ini_set('session.gc_maxlifetime', SESSION_TIME_OUT);
ini_set('session.cache_expire', SESSION_TIME_OUT);
session_start();

    Another alternative is to drop memcached and use a memory resident sqlite3 database instead for session storage, I don’t think the performance on your production environment will be much different in both cases.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search