PHP session directory full?

Question

I was hoping somebody could give me some advice please. I'm running a CentOS 6 server and over the last couple of days my disk usage has gone from 60GB to 135GB (98% full). I believe the issue may be to do with the PHP session directory (/var/lib/php/session) as this seems to be massive (I cannot ls or rm), there must literally be millions of files in this directory.

1. How can I remove this directory? rm is not working here and I've tried also to rsync replace an empty directory but that too takes eternity.

2. If this is causing the issue - why is PHP not removing these files automatically?

3. Is there likely to be any logging somewhere that could point me in the direction of an exploit, DDOS or failure?

Thanks

Solution 1

The default config of Ubuntu is that PHP does not expire sessions but there is a cron job which deletes old files. A full discussion of this would take some time (IMHO, it's a very bad idea) however I'm not aware of Redhat taking a similar approach.

You have not provided any details of your session config. This situation can arise due to the values for any of session.gc_probability, session.gc_divisor or session.gc_maxlifetime. Setting the defaults of 1, 100 and 1440 should ensure a reasonably homeostatic system once you have cleaned out the files as described in the other answers.

You have not said how many concurrent sessions you see on your system, their average size, nor the filesystem they are stored on. If you expect more than about 300 sessions (depending on filesystem) the you should consider using a directory tree rather than a single directory to store the files; prefix the session.save_path with 1 or 2 (assuming this is not a NFS server supporting a cluster of servers, in which case you should move to a different architecture).

Matt mentions it might be the selinux config. If this is allowing files to be created but never deleted. While this is possible, it would suggest the config on the system is seriously messed up. If this is the case (check your audit log) then you should probably to a clean install and restore your application over it.

It's very unlikely to have anything to do with bad programming.

Solution 2

sudo find /var/lib/php/session -type f -delete will work better than sudo rm /var/lib/php/session/* because expansion of * is hardly possible for big lists of files.

Solution 3

It sounds like your application is creating sessions but never destroying them. This could be poor programming and a mix of bad environment settings.

If you want to remove those session files you need to use sudo as they're likely not owned by your user.

sudo rm /var/lib/php/session/*

I would not remove the entire session directory.

Another thing is to adjust the PHP Session timeout to a smaller interval.

Comments

[kinggs]

Thanks for your answer Matt. Sessions currently have a timeout value of 5 minutes) but I agree I will need to go through some scripts and destroy sessions appropriately. It's just strange as there has been virtually no code changes for months and suddenly its boomed. I'm logged in as root so shouldn't need to sudo - I think there's just too many files to run rm

[Matt O.]

Another thing to check is /var/log/httpd and selinux to make sure PHP can even delete the files. If it can't, you'll need to modify the permissions of selinux to allow PHP to modify those files.