ID: 32330
Comment by: sean at oteams dot com
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Session related
Operating System: *
PHP Version: 6CVS, 5CVS, 4CVS (2005-03-17)
New Comment:
I struggled for several days with the "Failed to initialize storage
module: user" problem. I read everything I could find on php.net and
in this bug database. Finally, what solved the problem for me was
this:
Whenever I made a call in my code to session_start(), I used an include
statement to include the following from an include file:
<?php
ini_set("session.save_handler", "files");
session_start();
?>
And that did it.
Previous Comments:
------------------------------------------------------------------------
[2006-01-16 16:41:52] ajithts at gmail dot com
Hi folks,
I have also had the same problem. My /tmp was not a separate partition
and it had full permissions.
I have then changed session.save_handler to "files" in php.ini.
Initially it was "user". Everything worked perfectly after I have
restarted httpd saving the changes.
Thanks and regards,
Ajith
------------------------------------------------------------------------
[2005-06-04 00:25:54] [EMAIL PROTECTED]
PS(mod_data) gets set to NULL with these:
session_write_close(),
session_module_name('foo'),
session_destroy()
------------------------------------------------------------------------
[2005-05-21 19:19:42] [EMAIL PROTECTED]
I think you are on the right track mfischer. It looks like PS(mod) and
PS(mod_data) can get out of synch which would cause this. And I think
all the others with seemingly unrelated issues are actually related.
If PS(mod_data) leaks out of the per-request sandbox and infects
subsequent requests all it takes is one application on a server to use
its own session handler and it could affect other seemingly trivial
standalone session apps on that server.
------------------------------------------------------------------------
[2005-03-31 16:37:51] evenh+phpbug at pvv dot ntnu dot no
I experienced this one too, but only when using tavi.sourceforge.net.
This intrigued me, and I've developed a little script to give
information related to this issue.
The script at http://tavi.sourceforge.net/bug32330.php shows a counter
which jumps around at it own free will, seemingly. This due to the
changing host underneath, see changing $_SERVER['SERV_ADDR']. The
script always uses /tmp, and it's always writeable, but it's not on the
same computer!
This could be fixed by using a common path, as is done in
http://tavi.sourceforge.net/bug32330fix.php . And now the counter
works, and I don't get the "Failed to initialize..."-message either.
The reason for not getting the message, I've experienced, could be
related to accidentially calling session_start() twice... Either in the
same script, or script running in concurrent time space. Or maybe the
lack of session_write_close()?
Note that both the supplied script would include phpinfo() if adding
"?a" (or anything at all) after the script name. The scripts will be
available for some weeks. Feel free to copy them if needed... ;-)
But the messages seems to have gone away, so I'm happy. For now.
Regards,
Even Holen
------------------------------------------------------------------------
[2005-03-17 10:37:29] [EMAIL PROTECTED]
I see that the php_session_destroy() is called in php_session_decode()
too..
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/32330
--
Edit this bug report at http://bugs.php.net/?id=32330&edit=1
