Make a quick vote 🗳 ️How do you refer to SuiteCRM extensions: add-ons or plug-ins? Click here to have your say 👈

How to cleanup session files

I have more than 10K zero byte files in my session folder. It seems they are created every second or so.
Any idea why these are being created? Is there something that I need to set to cleanup session files?

Tony

Search the web for this as a PHP issue, not a SuiteCRM issue.

You might have permissions issues and the files can’t be written to. Or maybe it now has so many files that you ran out of disk space, or inodes. Cleaning it once might solve you problem for good. (just maybe)

Upgrading PHP and web server might also help

@pgr, the problem is not a disk space issue at this time. All of my packages on the server are up to date. The permissions of the session folder and files are 775 / www-data:www-data.

Since this problem only started after I enabled the cron.php task, I looked into the scheduler process. What I have found is that cron.php is creating a session id only when these four schedules are ran:

Process Workflow Tasks
Check Inbound Mailboxes
Run Email Reminder Notifications
Run Report Generation Scheduled Tasks

Enabling any other schedule does not create the session file.

Still trying to figure out why these schedules are doing this.

Tony

Which user is your cron job running under?

Who owns the session folder? What are the exact permissions on that folder (the folder itself, not just the files in it). Please include everything, SetGID, SetUID, etc

ls -al session_folder

Yea, No problem…

total 936
drwxrwxr-x  2 www-data www-data 802816 Jan 14 11:44 .
drwxr-xr-x 21 www-data www-data  20480 Jan 14 10:01 ..
-rw-------  1 www-data www-data  77670 Jan 14 11:44 sess_cmr5d2hi2q4iv51rhf4rhak17h
-rw-------  1 www-data www-data  56852 Jan 14 11:41 sess_l1r6ou9bv672tit985nso91qth
-rw-------  1 www-data www-data      0 Jan 14 11:44 sess_mmg04boik1op7fsmeqbl0eham1

And the conjob is running under which user?

See explanations about the multiple crontabs here, if you need them:

Sorry I left that off, the crontab tasks are under www-data user.

root@dash-dev:/var/www/demo-SuiteCRM-7.11.15/session# crontab -u www-data -l

          •  cd /var/www/demo-SuiteCRM-7.11.15; php -f cron.php > /dev/null 2>&1

So I’ve run out of permissions issues to explore… I think your set up should work.

So falling back to your hypothesis that somehow the sessions aren’t getting deleted because the code isn’t finishing - can you get any further clues about this? Have you been looking at the php_errors.log? And suitecrm.log, of course?

This continues to be an issue for me.

When I installed the system(s) I created a folder in the suitecrm folder named ‘session’ and entered this into the install script. All session files are placed in this folder and every time the cron.php file runs (every minute) it generates three - zero byte files. It looks like none of the session files are being deleted as the number of files continues to grow every minute.

I am running on a Debian system and have found some websites that speak about when using alternate session folders that you would have to manage your own session file cleanup. Does SuiteCRM manage any session cleanup or is it being left up to the OS?

If SuiteCRM allows you to use an alternate session folder then shouldn’t SuiteCRM manage those session files separately?

Clearing out the $sugar_config[‘session_save_path’] variable only places the session files inside of the default session folder /var/lib/php/sessions.

Cleanup is still not happening. Anyone else having this issue on Debian boxes?

Tony

When using the default directory location, are the files also 0 bytes?

Yes they are, these files are generated when the cron.php is ran. As I mentioned before:

Since this problem only started after I enabled the cron.php task, I looked into the scheduler process. What I have found is that cron.php is creating a session id only when these four schedules are ran:

Process Workflow Tasks
Check Inbound Mailboxes
Run Email Reminder Notifications
Run Report Generation Scheduled Tasks

Enabling any other schedule does not create the session file.

Also to note, session files in these folders > 0 bytes are created when a user logs in. These files also are not removed.

Which user’s crontab are you using?

Using www-data for the user for the cron.php

I would try, as a test, giving wide open permissions on your session directory to see if it changes anything. Make the directory 2777 and the files 777.

An update on the session files.

Changing the permissions as you mentioned is allowing the cleanup process to remove session files every 30 minutes on files older than 30 minutes on the default session folder (/var/lip/php/sessions).

I also noticed that the session files are now being created with www-data:root ownership and permissions of 600.

Next is to figure out why the cron.php processes are leaving session files around even though the cron.php has

if (session_id()) {
    session_destroy();
}

near the end of the file.

Tony

Ah ok, so it is a permissions issue.

Watch for the SetGID and SetUID bits in the parent directory, and the user and group that owns the parent directory. . That’s what controls the ownerships of the newly created files.