Running session garbage collection with a cron on CI3

I'm having difficulty getting any sort of garbage collection working in CI3 on Ubuntu. This is an inherited project so I'm not sure if this has ever worked. I'm running a couple of CI apps on the same server, and am using different session paths, so I'd like to implement a cron-based cleanup to have better control when it happens.
I have seen suggestions here and elsewhere to use CI's own gc() method from Session_files_driver.php. Can someone help me understand how to do this please? 
I can't work out how to access the gc() method from my own CLI-based PHP script. I've fiddled around with this for a day or so without success so it's time to ask for help 
Thank you!

@MereDev ,

Have you tried setting the sess_regenerate_destroy to True (https://codeigniter.com/userguide3/libra...references).

Thanks @php_rocs , I'd hadn't tried that, but just have though. I see no sign that gc() is running at all.

Here's what I have set which I _think_ should force garbage collection every time:

php ini:
session.gc_probability = 1
session.gc_divisor = 1
session.gc_maxlifetime = 1440

config.php:
$config['sess_driver'] = 'files';
$config['sess_cookie_name'] = 'mphsession';
$config['sess_expire_on_close'] = true;
$config['sess_encrypt_cookie'] = true;
$config['sess_expiration'] = 1440;
$config['sess_save_path'] = '/var/www/path-to-root/application/sessions';
$config['sess_match_ip'] = false;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = true;
$config['sess_use_database'] = false;

I was so unsure that CI sessions were being used that I stuck some debugging in system/libraries/Session/Session.php constructor, and also in nano system/libraries/Session/drivers/Session_files_driver.php. I can see from the logs that the session constructor runs, and the open method, but the gc method doesn't. Can your or anyone tell me what actually fires the gc method?
Alternatively, tell me how I can fire it myself from a cron script?

Cheers!

@MereDev ,

I forgot to ask specifically what version of CI are you running? Is it current?

It's 3.1.10 @php_rocs

I've still not been able to get Garbage collection to fire at all.

So for now I'm going to use my own CRON to manually delete session files from `/var/www/path-to-root/application/sessions`.

But if anyone ever has an answer how to do this the 'CodeIgniter' way, I'd love to hear it.

Thanks.

I've still not been able to get Garbage collection to fire at all.

So for now I'm going to use my own CRON to manually delete session files from `/var/www/path-to-root/application/sessions`.

But if anyone ever has an answer how to do this the 'CodeIgniter' way, I'd love to hear it.

I have just noticed loads of expired session files (like 27mb) in my Codeigniter 4 installation. I also can easily deal with those via a cron script, but if there was a native way to achieve this, would be so much nicer.

==

Donatas G.

Have a look at sessionRegenerateDestroy in the config file make sure that directory has the appropriate write permissions as per the documentation.

Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com

Have a look at sessionRegenerateDestroy in the config file make sure that directory has the appropriate write permissions as per the documentation.

Documentation says the parameter of sessionRegenerateDestroy instructs "Whether to destroy session data associated with the old session ID when auto-regenerating the session ID. When set to false, the data will be later deleted by the garbage collector."

So it seems it would reduce the number of remaining files, but it would not affect the files of sessions that expire quietly. In any case it is apparent that the garbage collector is not really working, as „the data will be later deleted by the garbage collector“ does not seem to ever happen.

==

Donatas G.

If that is indeed the issue and you have set the correct file permissions, I would raise that as bug.

Practical guide to IgnitedCMS - Book coming soon, www.ignitedcms.com