27

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}
rink.attendant.6
  • 44,500
  • 61
  • 101
  • 156
Hannes
  • 8,147
  • 4
  • 33
  • 51

6 Answers6

16

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

Community
  • 1
  • 1
robertbasic
  • 4,325
  • 1
  • 27
  • 25
  • already tried that one, brought me from 1 fail out of 20 to 20 fails out of 20 :( – Hannes May 31 '10 at 08:02
  • 3
    +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. – Horen Mar 14 '13 at 09:01
  • Got the error but I have `session.gc_probability = 0` already so this didn't solve anything for me. – BadHorsie Jun 28 '17 at 13:12
13

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

Toz
  • 162
  • 1
  • 2
  • 10
    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! :) – evildead Nov 02 '11 at 17:41
  • @Hannes and to all others... Please check http://stackoverflow.com/q/3723316/415865 if you find relevance! – Vikas Nov 24 '12 at 06:52
11

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.

Rob
  • 111
  • 1
  • 2
5

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"
hakre
  • 193,403
  • 52
  • 435
  • 836
Brady Olsen
  • 682
  • 7
  • 6
2

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
BadHorsie
  • 14,135
  • 30
  • 117
  • 191
  • Uhm, thanks … i never really solved this Problem, but on the other hand – that was 7 years ago :D – Hannes Jul 10 '17 at 12:00
1

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.

Artem Gordinsky
  • 616
  • 6
  • 21