Zend_Session / Zend_Auth randomly throws Error Message ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13)

Question

I'm currently working on a new Application using (among other things) Zend_Auth but, for whatever reason, this Error Message is showing up at any location totally randomly (or so it seams)

Zend_Session::start() - /home/hannes/workspace/develop/library/Zend/Session.php(Line:480): Error #8 session_start() [function.session-start]: ps_files_cleanup_dir: opendir(/var/lib/php5) failed: Permission denied (13) Array

• #0 /home/hannes/workspace/develop/library/Zend/Session/Namespace.php(143): Zend_Session::start(true)
• #1 /home/hannes/workspace/develop/library/Zend/Auth/Storage/Session.php(87): Zend_Session_Namespace->__construct('Zend_Auth')
• #2 /home/hannes/workspace/develop/library/Zend/Auth.php(91): Zend_Auth_Storage_Session->__construct()
• #3 /home/hannes/workspace/develop/library/Zend/Auth.php(141): Zend_Auth->getStorage()
• #4 /home/hannes/workspace/develop/xxxxxxx/application/controllers/AdminController.php(10): Zend_Auth->hasIdentity()
• #5 /home/hannes/workspace/develop/library/Zend/Controller/Action.php(133): AdminController->init()
• #6 /home/hannes/workspace/develop/library/Zend/Controller/Dispatcher/Standard.php(262): Zend_Controller_Action->__construct(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http), Array)
• #7 /home/hannes/workspace/develop/library/Zend/Controller/Front.php(954): Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
• #8 /home/hannes/workspace/develop/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
• #9 /home/hannes/workspace/develop/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
• #10 /home/hannes/workspace/develop/xxxxxxx/public/index.php(26): Zend_Application->run()
• #11 {main}

Gyre

Answer 1

A solution is to set the session.save_path in the php.ini file to a writable directory. for example: session.save_path = "/tmp". Switching the session garbage collection off in the first example is not a good idea. The second example does not work on Ubuntu 10.04

Viable

sorry, just came up here. This is a bad solution. Why? Because it is intedend that noone other than root can enter this directory. I think on a webserver running php, the session directory one of the most vulnerable dirs. Suppose you have a exploitable webapp, which gives you read access to /tmp, the attacker can hijack any session which is currently active only by getting the filenames. God knows what vulnerable data lies in the session itself. To sum up, IT IS A VERY BAD IDEA TO PUT SESSIONS UNDER /TMP. End of story! :) – Stubstad

@Gyre and to all others... Please check https://mcmap.net/q/167407/-what-is-causing-quot-unable-to-allocate-memory-for-pool-quot-in-php/415865 if you find relevance! – Submersible

Answer 2

Apparently this issue is affecting mostly (only?) debian/ubuntu based systems and has to do with automatic session garbage collection.

The variable session.gc_probability was set to 1 in the php.ini which means there is a 1% probability for the garbage collector to run and clean up the directory /var/lib/php5 where the php sessions are stored.

Apparently this folder is not writable by www-data resulting in the mentioned error and throwing the Zend exception. Setting session.gc_probability to 0 solved the problem. The session folder is cleaned up by a cron job anyway, so no need for the php garbage collector to even run.

From http://somethingemporium.com/2007/06/obscure-error-with-php5-on-debian-ubuntu-session-phpini-garbage

Rosalie

already tried that one, brought me from 1 fail out of 20 to 20 fails out of 20 :( – Gyre

+1: great answer! In case the link won't work in the future, here's the solution: The variable session.gc_probability was set to 1 in the php.ini which means there is a 1% probability for the garbage collector to run and clean up the directory /var/lib/php5 where the php sessions are stored. Apparently this folder is not writable by www-data resulting in the mentioned error and throwing the Zend exception. Setting session.gc_probability to 0 solved the problem. The session folder is cleaned up by a cron job anyway, so no need for the php garbage collector to even run. – Emmanuelemmeline

Got the error but I have session.gc_probability = 0 already so this didn't solve anything for me. – Olcott

Answer 3

Actually changing the directory of the session.save_path turns garbage collection off. That is why it now works for you. If you want garbage collection you can change the original directory owner to the php user "www-data"

chown www-data /var/lib/php5

In the alternative you can write a garbage collection script for the new directory.

Bloater

Answer 4

I had this problem with the Symfony framework also, the problem is php does not have permission to the session storage directory. Just change the session save directory to somewhere writable. In Zend Framework Bootstrap config ini:

resources.session.save_path = APPLICATION_PATH "/../data/session"

Bifid

Answer 5

If you are using PHP 7 on Ubuntu, ensure the PHP sessions directory is owned by the web server:

sudo chown www-data:www-data /var/lib/php/sessions

Olcott

Uhm, thanks … i never really solved this Problem, but on the other hand – that was 7 years ago :D – Gyre

Answer 6

I've had this issue on OS X 10.8.4 with MAMP, using the first Zend Framework. The directory set for session.save_path in php.ini by default is /Applications/MAMP/tmp/php. I was able to solve it only by deleting everything in that directory.

Overhead