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.

It's 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

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

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 user\'s home directory, /home/username
- wrong permissions and owner on ~username/.cagefs/tmp
After fixing it - tmpwatch works perfect.

Bogdan, it\'d be good to implement verbosing for tmpwatch and catch exit code of running tmpwatch in user\'s lve.

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