Today we are discussing an interesting error we every now then receive. Every now and then? Yes, a hard-to-reproduce problem that occurs every hundred page loads (on average). The error we are seeing in our Symfony2 project says something like:

session_start(): ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13)

Although we hadn’t yet seen this error on a live system we were seeing it  on our development VM’s at unwelcome times like during demo’s where it would cause a lot of embarrassment. Since we were afraid this bug might grow into some big monster if left alone, we promised our teams sysadmin some beers for getting to the bottom of this. Motivated by the idea of cold beers he found the following set of links which we all read carefully:

• http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage
• http://vvv.tobiassjosten.net/php/php-session-garbage-collection
• http://forum.kohanaframework.org/discussion/565/garbage-collector-error-with-sessions-on-debian/p1
• https://bugs.launchpad.net/ubuntu/+source/php5/+bug/316441
• http://stackoverflow.com/questions/6821532/php-warning-permission-denied-13-on-session-start

Our conclusion (but feel free to draw your own) is that the error is caused by PHP is trying to delete the session files while this is also being done by a cronjob put on the system by the Debian package maintainers of PHP. The package maintainers believed that the solution for cleaning up the session data in PHP is insecure. Therefor they introduced an alternative way of cleaning the session data. These solutions are not compatible, but somehow they often end up to be both enabled in Debian based setups. To be sure the problem is not existing anymore I checked the php.ini configuration (in “/etc/php5/apache2/php.ini”) of Ubuntu 12.04 LTS and there it says “session.gc_probability = 0″ which is the correct setting. Normally it should be set to “1″, but on a Debian based setup that also has a cronjob in “/etc/cron.d/php5″ for cleaning up old session files it should be set to “0″.

One of the reasons that so many people suffer from this problem may be that people normally upgrade there environments and not everybody reviewed the new package maintainers version of the php.ini and even if you would be doing that it is very easy to overlook this obscure change.

The alternative way of cleaning the session data that is introduced by the package maintainers of Debian only works if you use the default directory (“/var/lib/php5″) for storing your session data. This means that you will run in the opposite problem when you change the “session save path” to some custom directory. The lesson we learned? Be careful while upgrading and try to truly understand every line of configuration in your Linux system.