Fatal error on logout
TheRec - June 24, 2009 - 09:49
| Project: | Drupal |
| Version: | 6.x-dev |
| Component: | user system |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Description
Hello,
On a clean drupal-HEAD (from CVS) installation, if you are logged as User-1 and you put the site in Offline Mode and then click on "Logout" you should be redirected to frontpage and get the "Site offline" page, but instead you get the following PHP error on URL path "/user/logout" :
Fatal error: session_start(): Failed to initialize storage module: user (path: /tmp) in includes/session.inc on line 196It happens outside the Drupal error handler (it is a fatal error) so it is a white screen with only this error message. If you reload the page it displays the "Site offline" page, as expected. So it seems like the logout did work, but ended as an error when starting a fresh PHP session.
Tested on Linux environement and also Windows environement (Apache/2.2.8, PHP/5.2.9, MySQL 5.1.33) ... the "/tmp" path is writiable and I do no see any problem with session when I am logged in.
#1
Fatal error: session_start(): Failed to initialize storage module: user (path: /var/lib/php5) in .../drupal7/includes/session.inc on line 196
Call Stack:
0.0001 97136 1. {main}() .../drupal7/index.php:0
0.0142 2544352 2. menu_execute_active_handler().../drupal7/index.php:22
0.0163 2578248 3. call_user_func_array() .../drupal7/includes/menu.inc:402
0.0163 2578248 4. user_logout() .../drupal7/includes/menu.inc:0
0.0229 3217560 5. drupal_goto().../drupal7/modules/user/user.pages.inc:146
0.0236 3219752 6. drupal_session_commit() .../drupal7/includes/common.inc:336
0.0236 3219752 7. drupal_session_start() .../drupal7/includes/session.inc:222
0.0236 3219752 8. session_start() .../drupal7/includes/session.inc:196
Variables in local scope (#7):
$session_data = array ('batches' => array (1 => TRUE), 'updates_remaining' => array (0 => array (...)), 'messages' => array ('status' => array (...)))
#2
Ok, this is a PHP bug that is promised to be solved with PHP 5.3. Basically session_destroy also destroys the custom session save handler defined by Drupal. The workaround is to redefine this session save handler (session_set_save_handler) after calling session_destroy.
I am not sure how this is handled usually by Drupal community, but I left a comment near this call of session_set_save_handler with a reference to this bug.
#3
The last submitted patch failed testing.
#4
I think this bug is only triggered if you logout with some data in your session. In this case, drupal_goto() saves the session data even though the session was just destroyed. In other words the old logged-in session data is saved to the newly created anonymous session. I don't think this is desired or expected in most cases?
So an alternative solution would for logout to set
$_SESSION = array();and the PHP bug is not triggered because there's no attempt to write the empty session.#5
Yes, and I forgot to post here a link to an issue Berdir pointed out in IRC #477944: Fix and streamline page cache and session handling before I went to bed (I did post one there however). The solution you used is surely cleaner and it is used in the last patch of this issue (not at the same place) ;) So I guess we can mark this as a duplicate and wait for the issue with a bigger scope to be committed. Anyways, thanks for the time you spent looking into this :)
#6
I'm seeing this in 6.15 on PHP 5.2.6, the most recent available in Debian Lenny. The issue marked as a duplicate is quite a rewrite and won't go into Drupal 6. It happens on any logout with a non-empty $_SESSION. The strategy from #4 works.
#7
Still looks good to me, but this is just a reroll of #4 so needs other reviews. The fact that you need to unset the session variable is documented at http://www.php.net/session_destroy
#8
@drumm: that looks very weird. Can you reproduce this issue with a clean Drupal 6.15?
#9
The PHP bug mentioned above (which this patch works around) is a weird one and may be difficult to reproduce (it's fixed for PHP 5.3). The gist of it, as I understand, is some other PHP app running on the server sets custom session handlers, and then there is session handler leakage between apps (via the PHP apache module, so php5-cgi would not be affected).
#10
I found also this error in a installations with Pressflow
Confirmed that patch in #6 fixed it.
#11
Unfortunately, the patch in #6 does not work for me. Pressflow install on Ubuntu.