Logout action: SessionHandler::write(): Parent session handler is not open

[ghost]

Working through some tests using the bundled Security functionality, and we have noticed that on a logout action we are getting in our server logs:

[Mon Oct 29 16:43:14 2012] [error] [client xxx.xxx.xxx.xxx] PHP Fatal error:  Uncaught exception 'ErrorException' with message 'Warning: SessionHandler::write(): Parent session handler is not open in /web_dir/app/cache/dev/classes.php line 558' in /web_dir/app/cache/dev/classes.php:558\nStack trace:\n#0 [internal function]: Symfony\\Component\\HttpKernel\\Debug\\ErrorHandler->handle(2, 'SessionHandler:...', '/web_dir...', 558, Array)\n#1 /web_dir/app/cache/dev/classes.php(558): SessionHandler->write('e0ua5bnj0vneq97...', '_sf2_attributes...')\n#2 [internal function]: Symfony\\Component\\HttpFoundation\\Session\\Storage\\Proxy\\SessionHandlerProxy->write('e0ua5bnj0vneq97...', '_sf2_attributes...')\n#3 [internal function]: session_write_close()\n#4 {main}\n  thrown in /web_dir/app/cache/dev/classes.php on line 558

It seems this issue isn't unique to us as seen at:

https://groups.google.com/forum/?fromgroups=#!topic/symfony-devs/Q-f0lKT7OZ8

We are running a centos 6 machine running PHP v5.4.7 and Apache/2.2.15.

Anyone have any suggestions as to what is causing this and how we can eliminate this message on every log out?

[davedevelopment]

I ran in to this, probably related to this https://bugs.php.net/bug.php?id=63379

[marcosgdf]

Running PHP 5.4.4 under Mac OS X Mountain Lion

Fatal error: Uncaught exception 'ErrorException' with message 'Warning: SessionHandler::write(): Parent session handler is not open in /app/cache/dev/classes.php line 6318' in /app/cache/dev/classes.php:6318
Stack trace: 
#0 [internal function]: Symfony\Component\HttpKernel\Debug\ErrorHandler->handle(2, 'SessionHandler:...', '/Users/marcos/d...', 6318, Array) 
#1 /app/cache/dev/classes.php(6318): SessionHandler->write('e290059787e3be7...', '_sf2_attributes...') 
#2 [internal function]: Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy->write('e290059787e3be7...', '_sf2_attributes...') 
#3 [internal function]: session_write_close() #4 {main} thrown in /app/cache/dev/classes.php on line 6318

[tecbot]

same here.. debian

[makasim]

had this error in mail email too. Debian server.

Subject
        ErrorException: SessionHandler::close(): Parent session handler is not open
Summary
        Class: ErrorException
        Uri: http://foo.com/logout
        Code: E_WARNING
        Message: SessionHandler::close(): Parent session handler is not open
        File: /home/foo/www/releases/20121113194702/app/cache/prod/classes.php, Line: 546

Stacktrace
        exception 'ErrorException' with message 'SessionHandler::close(): Parent session handler is not open' in /home/foo/www/releases/20121113194702/app/cache/prod/classes.php:546
        Stack trace:
        #0 [internal function]: UniversalErrorCatcher_Catcher->handleError(2, 'SessionHandler:...', '/home/foo/w...', 546, Array)
        #1 /home/foo/www/releases/20121113194702/app/cache/prod/classes.php(546): SessionHandler->close()
        #2 [internal function]: Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy->close()
        #3 [internal function]: session_write_close()
        #4 {main}

[dfinkler]

i am seeing this too.. ubuntu / php 5.4.9

[ruudk]

Same here: Cent OS / PHP 5.4.9

[smottt]

Same. Ubuntu / 5.4.9

[crevillo]

same, ubuntu / 5.4.9

[mvrhov]

ping @Drak

[ghost]

UPDATE: This issue has been fixed in PHP so I'm assuming it will make it to the next releases of PHP 5.4.11 and PHP 5.3.21.

[tyx]

Hi,

Anyone can confirm this bug is fixed with updating on PHP 5.4.11 ?

Thanks

[tyx]

So I confirm it is fixed with 5.4.11 ;)

[ghost]

And I guess it will also be fixed then with the latest 5.3.21 - it should be.

[xr09]

Here is a temporal fix for anyone without the possibility to upgrade PHP.

https://groups.google.com/group/symfony-devs/browse_thread/thread/43e7f494a4fb399f/ab041c9f85d7eb9e?lnk=raot&pli=1

[ghost]

Ticket should be closed. There is nothing more we can do and the problem is fixed in PHP.

[saem]

This should not be closed. It is clear that it doesn't work in PHP 5.4.x, where x is at the very least lower than 11.

The check should be changed such that it checks against the minor revision number and fall back to the old method, rather than being broken for a number of PHP 5.4.x. versions.

[ghost]

There really is nothing that can be done, it's a pretty serious bug in PHP 5.4 less than 5.4.11. The bug does not exist in PHP 5.3

[saem]

It's simply a warning, which gets converted to an Exception, IIRC. Why can't a range check be done, then supplement an implementation that catches the exception, checks the message/code, if it matches, suppress, otherwise rethrow?

Being unusable for the current version in Ubuntu 12.10, and a number of other distributions seems far worse than some cruft to work around this.

[Nercury]

So basically you suggest every developer to go code their own fallback solutions in their own forked symfony repo instead of fixing it in the same place? "Nothing can be done" does not work for some of us, and we will have to write some nasty code ourselves.

[rKow]

There is a simple solution, look here: http://ferdinandfly.blogspot.com/2013/06/symfony2-php-warning.html
"the solution for no way to upgrade php is" :
// in security.yml
logout:
...
invalidate_session: false

But it should be only temporary solution.

[ghost]

I'd also like to put the problem is perspective just for clarity. The issue only exists for less than PHP 5.4.11. PHP 5.4 accounts for 3.6% of the entire PHP eco system, and versions less than 5.4.11 account for 40% of PHP 5.4 websites and just 1.04% of all PHP websites. 3% of websites are using PHP 4 so while it's a problem, it's not huge and there is a temporary solution until you can upgrade to PHP 5.4.11 or above.

Source: http://w3techs.com/technologies/details/pl-php/5.4/all and looking at the historical trends.

[fabpot]

Reopening this ticket as we should add a check in the Distribution bundle to warn people about this problem as so many developers hit this issue in the past.

[ghost]

It might be good to reference the workaround in the documentation as well.

[Pop-Code]

+1

[ironbone]

I confirm this problem (only in dev enviroment) in OpenSuse, PHP 5.3.17 (cli)

[azatyan]

Ubuntu, PHP 5.4.9 - problem found

[fabpot]

Closing now as I have added a recommandation in the distribution bundle. see sensiolabs/SensioDistributionBundle@2a518e7

[ibtihelfekih]

I resolved the problem of logout with adding invalidate_session : false
Maybe one of you need it :)
firewalls:

    main:
        pattern: ^/
        logout:     
            path: /logout
            target: /
            invalidate_session: false

[stof]

@AlmogBaku The discussion above is telling that the bug is fixed in PHP 5.4.11. 5.4.9 is an older version, so a buggy one

[reecefowell]

What version of Symfony is this regarding?

I just upgraded to Symfony 2.4 today and bam, i get hit with this, was fine on 2.1/2.2/2.3. And i never changed/updated my PHP version, it was the same all along (PHP 5.5.7).

So i am a little confused, as this topic seems quite old now. Was this first introduced in 2.4 or earlier? And If earlier, how come i am only just experiencing this now on 2.4 and with a version of PHP exceeding 5.4.9 which claims fixes the issue? (as prior mentioned i am on PHP 5.5.7).

Anyone can enlighten me here please?

Basically:

1. Which version of symfony was this bug introduced? i know which version of php, just need to know symfony version. (only just showing up for me on 2.4).
2. Which version of PHP closes the bug? As i am on 5.5.7, or is this ongoing? Otherwise why am i only experiencing this now?
3. Is this issue resolved with Symfony? If so what am i doing wrong?

Thanks!

[Pop-Code]

1. Which version of symfony was this bug introduced?
   => 2.2
2. Which version of PHP closes the bug? As i am on 5.5.7, or is this ongoing? Otherwise why am i only experiencing this now?
   PHP > 5.4.11
3. Is this issue resolved with Symfony? If so what am i doing wrong?
   This is not a bug related to symfony, but related to php.
   The workaround was to add a recommandation in the distribution bundle (sensiolabs/SensioDistributionBundle@2a518e7)

[reecefowell]

Hmmm thats weird then.

As i have SF2.4 including all the standard deps that ship with 2.4, and a PHP version exceeding the minimum (by quite a bit), also, SensioDistributionBundle is up to date.

I trashed my cache and rebuilt it, but no joy.

Also, I have added the config invalidate_session: false, but still the problem persists.

What could it be?

I have a Sandbox ready to go with Vagrant+Puppet via Puphpet if anyone knows how to solve this and can duplicate the error. Appreciate any help i can get. Thanks.

[reecefowell]

I solved the problem, and wrote about it here

[diegosainz]

@reecefowell the problem you describe in your blog is regarding SessionHandler::read() when trying to read the session from the configured localtion and not the issue described here that is about a PHP bug triggered with SessionHandler::write().