PHP – Fix ‘Session Directory Full’ Error

linuxPHPsession

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

Best Answer

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.

Related Topic