Can I safely delete all content in /var/lib/php5?

Tags: ,



I have over 5 million session files in /var/lib/php5
I would like to delete all files in this folder using rm *, however I’m not sure if there are other files other than the session files in that directory that should not be deleted.

Through SSH it took a few minutes to make the file count and I’m not sure I can navigate through there with all these random filenames.
The setup is ubuntu lucid linx, apache 2 and php5. In the most common of setups are there other folders / files in /var/lib/php5 that I should not delete?

Edit The reason I want to remove the files is because I moved session handling to a database and don’t need any of the files anymore.

Answer

Let PHP’s gc perform cleanup by itself. Find php.ini and change session.gc_probability to something bigger, save it and restart Apache (call any php script). It says here http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

In Debian and Ubuntu, /var/lib/php5, where the session data is stored,
has permissions of drwx-wx-wt and should only be cleaned by a cron
script. So, the package maintainers disable automatic session garbage
collection.

Or you could try to put ini_set('session.gc_probability', 100); session_start(); (if your session.gc_divisor is equal to 100) in one of your scripts and call it. The best way is to put in empty php file, because it might perform cleanup for a very long period of time.

ps: I would also try to leave session.gc_probability 1 and set session.gc_divisor to 1. It should call gc at every run, but you need it just for a directory cleanup.

And check your cron /etc/cron.d/php5 – it should run every half an hour to purge session files in the /var/lib/php5/ directory.

pps: found interesting comment

This does not disable it (it is commented out). The default within the
engine is still used – phpinfo() shows the value to be 1. There is a
problem with garbage collection in Debian (and thus Ubuntu) but that’s
due to PHP wanting to vacuum garbage that has already been removed by
the cron script. This causes an error that may be displayed on the
unlucky page.



Source: stackoverflow