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:
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).
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,[] => …
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.
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) {
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With