问题
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,[] => …
回答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.
回答2:
If you're getting Zend_Session_Exception after upgrading from PHP 5.3 to PHP 5.4+ the problem can be caused by E_STRICT errors. In PHP 5.4 E_STRICT became part of E_ALL.
You can disable strict errors in your php.ini:
error_reporting = E_ALL & ~E_STRICT
You would expect that the exception will be gone, but the problem is in the following lines in Zend_Session class:
$errorLevel = (is_int(self::$_throwStartupExceptions)) ? self::$_throwStartupExceptions : E_ALL;
// some code omitted
set_error_handler(array('Zend_Session_Exception', 'handleSessionStartError'), $errorLevel);
// some code omitted
set_error_handler(array('Zend_Session_Exception', 'handleSilentWriteClose'), $errorLevel);
Basically, Zend_Session_Exception is registered as an error handler and it will be called for all error levels (regardless to the settings of the error_reporting setting) if you don't set the throw_startup_exceptions option.
The solution for me was to set option throw_startup_exceptions to false until I fix the strict/notice errors in the code.
You can set it in application.ini:
resources.session.throw_startup_exceptions = false
or by calling Zend_Session::setOptions()
回答3:
Clear your browser's cookies. PHP sessions seem to store the SID in a cookie, so when I switched from php 5.3 to 5.4 there seems to have been some problems dealing with existing cookie values for session. simply clearing the session data was not enough- try clearing all session data and also deleting browser cookies.
回答4:
In my case it was just allow write mode for the session directory
来源：https://stackoverflow.com/questions/11265245/why-does-my-php-with-zend-framework-go-crazy-about-session-started-since-updat