Question

I never had problems with any of my projects. Just recently when I ran a pacman-update in arch linux (which updated to 5.4) many of my projects where not runnable anymore.

Interestingly the problem only occurs as soon as the session-file was created on the filesystem. I mean, I can call the website a first time, as long as the /tmp/sess* does not exist.

When I want to call it a second time and /tmp/sess* has already been written, I get the following error (including stacktrace, Zend Framework).

Zend_Controller_Exception: session has already been started by session.auto-start or session_start()#0 /srv/http/bahasa/library/Zend/Session/Namespace.php(143): Zend_Session::start(true)
#1 /srv/http/bahasa/library/Zend/Auth/Storage/Session.php(87): Zend_Session_Namespace->__construct('Zend_Auth')
#2 /srv/http/bahasa/library/Zend/Auth.php(91): Zend_Auth_Storage_Session->__construct()
#3 /srv/http/bahasa/library/Zend/Auth.php(141): Zend_Auth->getStorage()
#4 /srv/http/bahasa/library/Skoch/Controller/Plugin/Navigation.php(59): Zend_Auth->hasIdentity()
#5 /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php(287): Skoch_Controller_Plugin_Navigation->dispatchLoopStartup(Object(Zend_Controller_Request_Http))
#6 /srv/http/bahasa/library/Zend/Controller/Front.php(928): Zend_Controller_Plugin_Broker->dispatchLoopStartup(Object(Zend_Controller_Request_Http))
#7 /srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php(97): Zend_Controller_Front->dispatch()
#8 /srv/http/bahasa/library/Zend/Application.php(366): Zend_Application_Bootstrap_Bootstrap->run()
#9 /srv/http/bahasa/public/index.php(30): Zend_Application->run()
#10 {main} in /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php on line 312

Of course I already checked other answers for this problem on stackoverflow, but:

• session.auto-start is set to 0
• there is no session_start() call at a place outside library/Zend/ (did grep -r on the whole project dir)
• writing Zend_Session::start() in Bootstrap.php (as a bugfix) lead to new fatal errors
• filesystem rights are ok, /tmp has 777 and the created sess-file has http rw (777 does not change the behaviour).

Also as said it strangely happened as soon as I updated from PHP 5.3 to PHP 5.4. The problem is, downgrading does not seem to work (then the mysql-libraries are broken somehow).

And as already mentioned, the most strange thing to me is, that it only happens when the session-file has been created in /tmp. When /tmp does not have a session file, it all works perfectly.

And yeah, it’s not only my own project affected, but also that I am working on for another company (which runs like charms on their server and their local PCs), so that also sort of contradicts the problem within my own code (as same thing happens at two Zend Framework projects).

And of course my project also runs like charms on my online webspace with PHP 5.2.12.

I guess the PHP notice before could also be interesting:

Notice: Array to string conversion in /srv/http/bahasa/library/Zend/Session/Exception.php on line 58

Call Stack:
0.0009     134352   1. {main}() /srv/http/bahasa/public/index.php:0
0.2805    3703732   2. Zend_Application->run() /srv/http/bahasa/public/index.php:30
0.2805    3703756   3. Zend_Application_Bootstrap_Bootstrap->run() /srv/http/bahasa/library/Zend/Application.php:366
0.2806    3703876   4. Zend_Controller_Front->dispatch() /srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php:97
0.2873    3829732   5. Zend_Controller_Plugin_Broker->routeStartup() /srv/http/bahasa/library/Zend/Controller/Front.php:908
0.2873    3829820   6. Skoch_Controller_Plugin_Autologin->routeStartup() /srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php:237
0.2883    3840992   7. Zend_Auth->hasIdentity() /srv/http/bahasa/library/Skoch/Controller/Plugin/Autologin.php:12
0.2884    3841016   8. Zend_Auth->getStorage() /srv/http/bahasa/library/Zend/Auth.php:141
0.2960    3980864   9. Zend_Auth_Storage_Session->__construct() /srv/http/bahasa/library/Zend/Auth.php:91
0.2960    3981072  10. Zend_Session_Namespace->__construct() /srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87
0.2961    3981232  11. Zend_Session::start() /srv/http/bahasa/library/Zend/Session/Namespace.php:143
0.2968    3989956  12. session_start() /srv/http/bahasa/library/Zend/Session.php:469
0.2972    3997536  13. PropelAutoloader->autoload() /srv/http/bahasa/library/Zend/Session.php:0
0.3000    4060508  14. require('/srv/http/bahasa/application/models/bahasa/User.php') /srv/http/bahasa/library/propel-1.6.4/runtime/lib/util/PropelAutoloader.php:108
0.3377    4925056  15. Zend_Session_Exception::handleSessionStartError() /srv/http/bahasa/library/propel-1.6.4/runtime/lib/util/PropelAutoloader.php:16

However, Propel does not seem to have any session_start() within the own code, so that’s not the cause (propel also lies within the checked project director).

I personally do not see the full meaning in this notice yet, but the longer I look at it the more it seems to be related to the error (at least the stack trace, I mean the notice is only about array to string conversion).

Backtraces for calls to Zend_Session::start()

Okay, I found the backtraces when Zend_Session::start() gets called twice.

First:

#0  Zend_Session::start(1) called at [/srv/http/bahasa/library/Zend/Session/Namespace.php:143]
#1  Zend_Session_Namespace->__construct(Zend_Auth) called at [/srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87]
#2  Zend_Auth_Storage_Session->__construct() called at [/srv/http/bahasa/library/Zend/Auth.php:91]
#3  Zend_Auth->getStorage() called at [/srv/http/bahasa/library/Zend/Auth.php:141]
#4  Zend_Auth->hasIdentity() called at [/srv/http/bahasa/library/Skoch/Controller/Plugin/Autologin.php:12]
#5  Skoch_Controller_Plugin_Autologin->routeStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => ,[] => Array (),[] => ,[] => Array (),[] => ,[] => ,[] => module,[] => ,[] => controller,[] => ,[] => action)) called at [/srv/http/bahasa/library/Zend/Controller/Plugin/Broker.php:237]
#6  Zend_Controller_Plugin_Broker->routeStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => ,[] => Array (),[] => ,[] => Array (),[] => ,[] => ,[] => module,[] => ,[] => controller,[] => ,[] => action)) called at [/srv/http/bahasa/library/Zend/Controller/Front.php:908]
#7  Zend_Controller_Front->dispatch() called at [/srv/http/bahasa/library/Zend/Application/Bootstrap/Bootstrap.php:97]
#8  Zend_Application_Bootstrap_Bootstrap->run() called at [/srv/http/bahasa/library/Zend/Application.php:366]
#9  Zend_Application->run() called at [/srv/http/bahasa/public/index.php:29]

Second:

#0  Zend_Session::start(1) called at [/srv/http/bahasa/library/Zend/Session/Namespace.php:143]
#1  Zend_Session_Namespace->__construct(Zend_Auth) called at [/srv/http/bahasa/library/Zend/Auth/Storage/Session.php:87]
#2  Zend_Auth_Storage_Session->__construct() called at [/srv/http/bahasa/library/Zend/Auth.php:91]
#3  Zend_Auth->getStorage() called at [/srv/http/bahasa/library/Zend/Auth.php:141]
#4  Zend_Auth->hasIdentity() called at [/srv/http/bahasa/library/Skoch/Controller/Plugin/Navigation.php:59]
#5  Skoch_Controller_Plugin_Navigation->dispatchLoopStartup(Zend_Controller_Request_Http Object ([] => Array ([0] => _GET,[1] => _POST),[] => /de/,[] => ,[] => ,[] => de,[] => …

Answer 1

Okay, I found the error. It’s totally nothing you would have been able to find out, but the general answer might be interesting for others.

General answer

The notice really had to do with the error. The problem is, Zend_Session_Exception gets registered as error handler for session_start() and session_start() passed the small notice on to Zend_Session_Exception. Even though it’s only a notice (which does not get fired on the production system, thus it worked there), Zend_Session_Exception gets fired and it sets Zend_Session_Exception::$sessionStartError to an error.

As soon as such an error gets logged, the session will not be registered to Zend_Session. Even if session_start() returns true itself

You can see this in this line ($startedCleanly indicates the return value of session_start()):
if (!$startedCleanly || Zend_Session_Exception::$sessionStartError != null) {

Specific answer

In my special case, this all was due to a inheritance conflict. I did not add the parameters of Propels (database ORM) Base-classes to my subclasses. Then PHP sent a notice, that I should correct this.

Because such a Propel object lived within my session (User), the notice was fired exactly when session_start() was called. This is why Zend_Session_Exception was alerted. And then it went as described above.

Still open question

What I have not found out, is why this behaviour came up in PHP 5.4. I had not implemented the parameters before either, but it was never seen as a problem when resolving the session. Guess they have changed something in opening session-values.