Sess_1234567890... files?

Using Concrete / Help
1

My web hosting supplier just asked me to reduce the number of inodes I’m using by deleting obsolete files.

My obsolete files turn out to be in a directory tmp and have the form sess_000026968ad1413bc670bdf43da7f364

It turns out that I have nearly a million such files on one Concrete5 website 95k on another.

What are they, can I stop them and/or how best to remove/expunge them, please?

Version 8.2.1

Thanks,
Gordon.

2

These are the files visitor and login sessions are stored in. They should be cleaned up by the php environment, but it is not unusual for that to fail or to not be configured on the server or to be prevented by file permissions. Your first call should be to work out why the environment is not cleaning them up automatically.

You can just delete the entire directory content from the SSH command line, or delete all that are more than 2 weeks old (depending on your CLI skills). If you delete all, then all current users end up logged out and visitors forgotten.

Some sites with this problem handle it with a shell script to delete > 2 weeks old and run that through cron.

There may be someone who has posted a concrete automated job you can install to the site to do similar. I had one for 5.6, but it is not suitable for installing on v8.

There is also a cleaner for temporary files in my Extreme Clean addon. Extreme Clean - concrete5

3

Hi John,

That was much as I suspected. I’ve already mentioned to the web host that I think it should perhaps be a cron job. I’ll explore further. If php doesn’t deal with it, and/or I can’t get it done by cron, I guess I’ll have to run a clean-up script via ssh. Not hard, but a nuisance.

Thanks.

4

These session files should be cleaned up by PHP. But I’ve seen cases where the session garbage collection is turned off.

In the past these lines in an htaccess file have done the trick to turn it on and automatically old session files:

php_value session.gc_divisor 100
php_value session.gc_probability 1
1 Like
5

That’s useful to know. Thanks.

I’ll start by feeding this information to the hosting provider as I suspect they’ll have a number of sites with this issue. If they can’t or won’t do anything, I’ll definitely try that.

8

Sadly for me those lines caused my website to fail with “wrongly configured” responses. I may explore further.

9

Assuming you are on shared hosting, this is really something your hosting provider should help with. In my experience, the hosting provider will usually have some sane default settings already for garbage collection.

If your account uses cPanel, you can use the PHP INI editor to set these values.

10

I’ve seen similar problems when session files are stored in /tmp on shared hosting. VERY slow as the number of files there increases.

Try creating a tmp/ directory under application/files/cache, then add this array to your application/config/concrete.php:

'filesystem' => [
    'temp_directory' => DIR_FILES_UPLOADED_STANDARD. '/cache/tmp',
],

Then add this to your cron jobs (SSH crontab -e) or through your hosting control panel (modified for your directory structure), -mtime 14 is for 2 weeks:

10 0 * * * find PATH_TO_CONCRETE/application/files/cache/tmp -name sess\* -mtime 14 -delete

You can test it from SSH first to see what it would delete, like so:

find PATH_TO_CONCRETE/application/files/cache/tmp -name sess\* -mtime 14 -print

Hope that helps.

1 Like