Users .cagefs/tmp/ directory filling with thousands of session files

[hollowheartx]

I was looking into a disk usage issue for a customer and found that they had nearly 1 GB of temporary session files stored in /home/user/.cagefs/tmp/

In fact, there are currently nearly 197,000 of these files... some with todays date... some over 4 months old. The files all look like this:

-rw------- 1 username username 75 Jul 5 15:56 sess_fffcd441337ca45a72f1fd314756ec51
-rw------- 1 username username 96 Jul 20 16:07 sess_fffce04195a58c07cff8a0be35a7be03
-rw------- 1 username username 96 Aug 23 08:25 sess_fffd1e490ef386faf741e79f6ee3f964
-rw------- 1 username username 75 Jun 14 00:25 sess_fffd35f8eb321c6e034c02e4cafd6ce9
-rw------- 1 username username 75 Oct 1 23:43 sess_fffd8c5e81f81b1bccad9c06d0b1fffa

Sure, i can clear these files out, but this is masking a larger problem.

1) Why are these files here?
2) Should they be here?
3) How can they be automatically purged to stop this from happening to this or other customers in the future?

Thanks for any insight you can provide.

- Scott

[mike]

Open /usr/share/cagefs/cagefsctl.py and find def tmpwatch():
Replace string (line 3922 in cagefs-5.5-6.4.el6.cloudlinux.x86_64):

subprocess.call(cmd, stderr=dev_null, stdout=dev_null)

with this code, saving correct identing for python:

if VERBOSE:

subprocess.call(cmd)

else:

subprocess.call(cmd, stderr=dev_null, stdout=dev_null)

Then run:

cagefsctl -v --tmpwatch

Output of this command should help you to fix the problem.

[bogdan.sh]

Its not Ok to perform any modifications to source code, answering your questions:

1) Why are these files here?
2) Should they be here?
This depends from PHP and used softoware configuration, some websites could be configured to store session files in mysql databases, however by default all session files are in /tmp/ .

3) How can they be automatically purged to stop this from happening to this or other customers in the future?
CageFS do watch users tmp however it remove files that was not accessed in 30 days. This means if website is popular and it has 197,000 active users (those who log to site in past 30 days) session files will not be removed.

First, try launching cagefsctl --tmpwatch as is and check number of files, maybe this command was not executed. If files stays untouched - check access time for some of them ( stat /home/username/.cagefs/tmp/sess_xxyyzz ).

You may also reconfigure this process to remove files by modification time, cagefs use standard tmpwatch syntax. More: http://docs.cloudlinux.com/tmp_directories.html

[sqh]

Bogdan, this is a known bug. See Ticket: #JUX-649-26138

> Hello!
>
> I have found a bug in cagefsctl --tmpwatch command
> It will be fixed in the next release of CageFS
>
> Thank you for reporting the issue
>
> Anton Volkov,
> Developer,
> Cloud Linux Inc.

This problem is STILL not fixed, by the way. I do not know what release of "CageFS" will fix this... do you know?

- Scott

[mike]

Of course before such ugly way of detecting the problem, you should backup original file and after debugging, you should return it back.
In our case, after enabling "verbose" of tmpwatch we found out two problems:
- wrong permissions on users home directory, /home/username
- wrong permissions and owner on ~username/.cagefs/tmp
After fixing it - tmpwatch works perfect.

Bogdan, itd be good to implement verbosing for tmpwatch and catch exit code of running tmpwatch in users lve.

[bogdan.sh]

I was just informed by our developers that indeed that is caused by a bug, most probably we will release a hotfix this week. Internal case number that will be listed in release notes: CAG-392