Is the /tmp directory writeable by the web server and is there avaliable space in there?

-bash-2.05b$ ls -l
drwxrwxrwt   4 root  wheel     2048 Oct 17 11:37 tmp

/tmp is not a separate partition
/dev/da0s1a   4.7G   133M   4.2G     3%    /

See bug #32330 for similar issue. Do you use session_destroy() anywhere? Or session_decode()? 

A client of mine is having the same problem. The script uses:

session_start();
session_register('susername');
session_register('spassword');
session_register('sreferer');
session_register('susecode');

No destroy or anything special. If $username is set, than it sets the session $susername to $username. He tried accessing the page within a short time period after me, both passing the same username. However when I access it again it doesn't give me the error.

i have this problem as well.

as long as:
   php_value session.save_handler    user
is in my .htaccess file

session_start(); 

will not work.

I am also having this problem

Freebsd 4.8
php 4.3.10

RedHat 9
PHP 4.3.9 from RPM (php-4.3.9-11.rh90.art)
Zend Engine 1.3.0, Optimizer 2.5.5

I am experiencing the same problem: the error indicates storage module "user", yet php.ini has it set to "files", and nowhere in my code do I change it to "user".

The problem comes and goes as the page is reloaded.  A PHP page with no session code does not exhibit the problem.

My /tmp directory is world writable.

Todd

Please kindly pay attention to this bug.
It is REAL bug, not fantasy of 100+ man. Random session handler error.

No Feedback status is surely lame for this, as you are getting feedback.
There is no reproduce code because bug is "random bug under heavy load" class.

We hope for you.
Thanks.

My hosting company is unable to fix the random "Failed to initialize storage module" error and it is making my account unusable.  They cannot seem to fix it.  What is the story with this!?

We (as hosting company) are hoping that PHP team will track this bug down some day.
Indeed, we can do not much to help or to fix it.

This bug is hard to fix because it appears randomly, and there is no definite recreate scenario. There is assumption that this is http://bugs.php.net/bug.php?id=32330 bug, but I am not completely sure.

You may suggest your hosting company to lower average server load - it will help this bug to happen rarely or even at no times. Lower - I mean - something lower than 50% avg CPU load on 1CPU server or 80% on 2+ CPU server.
But that is only our hosting company workaround, not the solution.

I have now experienced this beast with a completely different hosting company.  They are both running 4.3.10 - is this fixed in 4.3.11?

Hi,

I'm experiencing this problem in at least 2 sites.

Since it's a error that appears in random, I wrote a simple script to try and reproduce the error. This is the script:

<?php
session_start();
header("Cache-control: private"); //IE 6 Fix
if ( !isset($_SESSION['ctr']) ) {
  echo $_SESSION['ctr'] = 1;
}  
else {  
  echo $_SESSION['ctr']++;
}   
?>
<meta http-equiv="refresh" content="10;url=test.php">

All it does is invoke "session_start()" and use one session variable. It then reloads itself every 10 seconds. On HOSTMANIL.ORG and HOSTMANIL.NET, the error comes up. But there is no pattern at all. Sometimes out of 20 refreshes, there's an error, half the time. If the error comes up, I have to do a manual refresh. I notice that the session variable is not destroyed at all. It continues counting from where it stopped. 

The problem is at one point in HOSTMANILA.ORG, it kept on coming up every 2 auto refreshes (and I do an F5). But now, it's was good for 45 straign auto refreshes before the error came up. That's how random the error is.

I do a lot of programming, mostly in PHP but I'm not "deep" technical. So I'm not sure if I'm missing something.

I'm running the scripts on 5 sites. These are all on different servers although all of them are from shared hosting services using cPanel / WHM.
    http://www.hostmanila.org/test.php
    http://www.hostmanila.biz/test.php
    http://www.hostmanila.net/test.php
    http://www.vcdpix.com/test.php
    http://www.smokedbangus.com/test.php

So far, it's only happened on HOSTMANILA.ORG and HOSTMANILA.NET.

Here's the rundown on each site:
HOSTMANILA.ORG (error)
Linux 2.4.30-gator_r1
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.11
cPanel 9.9.9-STABLE 15

HOSTMANILA.BIZ (fine)
Linux 2.4.30-1-s5
Apache 1.3.33 (Unix)
PERL 5.8.3
PHP 4.3.11
cPanel 10.2.0-RELEASE 82

HOSTMANILA.NET (error)
Linux 2.4.26-grsec
Apache 1.3.33 (Unix)
PERL 5.8.0
PHP 4.3.11
cPanel 10.0.0-RELEASE 7

VCDPIX.COM (fine)
Linux 2.4.20-24.9
Apache 1.3.33 (Unix)
PERL 5.8.1
PHP 4.3.9
cPanel 10.0.0-RELEASE 7

SMOKEDBANGUS.COM (fine)
Linux 2.4.20-20.7smp
Apache 1.3.33 (Unix)
PERL 5.8.4
PHP 4.3.10
cPanel 10.0.0-CURRENT 107

I can't imagine developing anything in PHP without making use of session_start() so I hope the issue is resolved.


Regards,

Gul
hostmanila.com

Please someone in PHP team confirm that you are reading from this bug (it has 'No Feedback' status).
Or may be we are writing for ourselves here?

Same problem here as described by "gul_murjani at yahoo dot com". PHP 4.3.10 is the version in use (phpinfo() can be seen at http://www.c64-wiki.de/test.php). I tried to change  session.save_path to a different path (by adding a php_value line into .htaccess), made the new directory world-writeable and verified that the session files do indeed appear there. They do appear there, and there's plenty of space for that directoty available (about 1GB, should be 'nuff for a few of these session files with <100 bytes each). And the bug still appears at extremely random intervals!

Best regards, Klaus

I added the following line near the beginning of my PHP code:

ini_set("session.save_handler", "files");

I have not seen the bug again after that, so far (clicked around like an idiot and everything worked fine). Which does not mean a lot, of course, due to the extremely random nature of that bug.

Can anybody else confirm that this workaround works (or maybe not)? If it does "solve" the problem, the root cause may seem to be that PHP sometimes takes the wrong session handler (not the one which is defined in PHP.INI, which is "files" as well (while the error message seems to indicate "user"?)).

Best regards, Klaus

I had the same problem, with the same error message, mainly
on a dotclear "weblog" application, on the manage section.

I put the PHP code given in the prepend file :
  ini_set("session.save_handler", "files");

and the error automagically disappear, for good (I hope!)

The "save_handler" is just defined in php.ini with value
"files", and not redefined anywhere else. It's strange
that I have to define it again in the code.

Best regards, gu!llaume

On our ES 3 machines, we worked around this bug by pre-pending and appending the following code to all scripts executed (via the php.ini) file:

[root@server root]# cat /tmp/auto_append_file.php 
<?php
if (ini_get("session.save_handler") == "user") {
        @ini_set("session.save_handler","files");
        @ini_set("session.save_path","/tmp");   
        @ini_set("session.use_cookies","1");     
}
?>

Since the error is never exhibited on a freshly spawned instance of apache, reducing the number of requests handled by apache (in Worker MPM mode) made sure that new children were spawned before old age increased probability of the bug; this seemed to be vital to make a 99% effective solution.

[root@server root]# httpd -l
Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

On our machine we also noticed that after testing this for workaround for 3 weeks we haven't used any swap on the machine as opposed to ~100MB previously, another desireable side effect.

I experience the same (sporadic) errors on my FreeBSD 4.11-RELEASE-p11 using php4-4.4.0 and apache-1.3.33.

The mentioned workaround (putting ini_set in an auto_prepend_file) is now in place and to be tested.

Additionally, i would be glad if the PHP crew would do something about this - it's really a shame to see that this bug still happens with 4.4.0.

Used the workaround mentioned two comments below, but experiencing still the same sporadic errors.

Any further hints are very appreciated.

I have this problem too and adding the the code with setting "session.save_handler", "session.save_path", "session.use_cookies" does not solve this problem. 

I use PHP Version 4.4.0

I'm experiencing the same problem, strange enough NOTHING i tried so far has solved it. I tried: 

Recompiling PHP
Downgrading PHP
Reinstalling Zend
Upgrading Zend

At a certain moment a harddrive of the server with this error went bad, and i had to do a complete reinstall on a different drive.. Strange enough.. the SAME error occured, while I have different servers with identical hardware and settings which run just fine.. without errors.

Is it possible this error has somehow got anything to do with hardware? bad memory or something? I simply find it too strange that i'm only experiencing this error on 1 of the 8 machines, and that even a COMPLETE re-install didn't work.

I'm using FC3 with Cpanel
PHP 4.4.0 with Zend Optimizer 2.5.10a

I was experiencing this problem on my server, and have managed to make it go away after reading comments in this post and experimenting a bit. details:

original setup:
/var/lib/php/session
owner root:apache
permissions: 770

test script from gul_murjani at yahoo dot com would fail after between 1 and 30 or so counts

modified permissions on directory to:
owner apache:apache
permissions 700

test script ran on five client computers to over 10,000 cycles without failing.

this fix is strange though as I have since changed the permissions back to the origial setup:

owner root:apache
permissions: 770

and the script has run without failing - no more errors - even after another thousands of cycles.

strange but true!

Hello

We "solved" it by adding an auto_prepend file to every .php executed on our servers:

[futurahost@mars lib]$ cat php.ini.prepend
<? session_module_name("files"); ?>

[futurahost@mars lib]$ grep auto_prepend_file php.ini
auto_prepend_file = /usr/local/lib/php.ini.prepend
[futurahost@mars lib]$

Anyway, we are very concerned about php developers completely ignoring this bug.

Without knowing about the code side of it, this bug reminds me of the php_value leak there was amoung virtualhosts in apache once - where the php_value_* from one virtualhost was leaked in to another.

while i was working on joomla admin module i got this error:
Fatal error: session_start(): Failed to initialize storage module. in /var/www/html/workspace/joomla/administrator/index2.php on line 34
as suggested by may forum i have changed  session.save_handler 
in php.ini to files.
but error is still there........is there any concrete solution for this problem

A workaround for this problem is to reset the session handlers for PHP before calling session_start for the second time. You can use the session_set_save_handler() function for this.

Running with this configuration,

FreeBSD FreeBSD 5.2.1-RELEASE-p9 #0: Wed Aug 4 19:02:38 CEST 2004 
Database Version:  MySQL 4.0.18  
PHP Version:  4.3.11  
Web Server:  Apache/2.0.52 (FreeBSD) PHP/4.3.11  
WebServer to PHP interface:  apache2handler
session.save_handler in php.ini set to files,

I see this problem with a low frequency (maybe 2-3 times every second day when working with updates to my CMS system all day). Doing a web search in the CMS community it seems that a number of people is strugling with this problem...

I'm hitting this same issue with php 5.0.3 on Debian 1:3.3.5-13 using a custom session handler that writes to MySQL database. It comes up intermittently, usually persists for a few seconds (all pageloads that take place over that time), then goes away.

The workaround of forcing session.save_handler to "files" is not working for me, nor do I think it's appropriate in this situation since I do want a user-defined handler after all.

I'm experiencing this bug as well and none of the fixes mention helped. I've got a production system where this is happening on right now. Every php application has is affected is just calling session_start(); 

If it helps the PHP developers out, I can give you access to the system for testing, monitoring, etc. Just let me know.

We have this problem to.

Nothing helps :(

still have same problem , user session empty and get out of the site.
try all what the guys said , nothing happened

Hy
i have this problem as well.

PHP version 4.3.11

Script index.php:
session_start();
ob_start();

/tmp -> /domanin_site/tmp/

we can pass session id to ensuser that session remains intact.. use SID it will help

Just to note: This error happens if the functions identified in session_set_save_handler are not defined at the time of the call.

Try disabling safe mode

> We are currently having problem with the same think at one of our servers.

Can your reproduce this with PHP 5.2.4 or greater? (in case we happen to release 5.2.5 in the meantime :)

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

System: FreeBSD 6.2-RELEASE
PHP Version 5.2.5
Apache Version 	Apache/2.0.63 (Unix)

This problem started after an server update (php+mysql+apache).
None of the solutions found here can fix it.

This bug is easy to repeat in following way:

1) Set session_save_handler to user based like DB
2) Start page like normal, start session etc
3) CHANGE your session_id BEFORE you print anything to your screen
3.1) Destroy the old session_id
3.2) set new session id with session_id('your_id')
3.3) Try start_session() which will produce error message

Problem is that system can not init custom session_save_handler in some odd reason. When changing session_handler to local files, anything goes normal. But with custom save handler like memcache or DB backend, code will fail.

When you refresh page, problem disappears.

I have tested this with Apache 2.2.8, PHP 5.2.5 and MySQL 5.1.23RC and with newest memcache.


--JT--

I use DB for sessions, and had the problem with session_destory (followed by session_start) as well.

I had this code in a prepend-db file:

$GLOBALS["mysql_session_handler"] = new mysql_session_handler;
			session_set_save_handler(
			    array($GLOBALS["mysql_session_handler"],'mysql_session_open'),
			    array($GLOBALS["mysql_session_handler"],'mysql_session_close'),
			    array($GLOBALS["mysql_session_handler"],'mysql_session_read'),
			    array($GLOBALS["mysql_session_handler"],'mysql_session_write'),
			    array($GLOBALS["mysql_session_handler"],'mysql_session_destroy'),
			    array($GLOBALS["mysql_session_handler"],'mysql_session_gc')
);

=====

So instead, I put that inside the class as a static function (the in the prepend, called that static function, mysql_session_handler::setHandler();) , then called it again after session destroy. i.e.

session_destroy();
			
mysql_session_handler::setHandler();


Problem sovled  - well, it's not, session_destroy should not destroy the save handler

I have the same problem:

"Fatal error: session_start(): Failed to initialize storage module: files (path: ) in...."

and i've put this line:

ini_set("session.save_handler", "files");

and nothing happens.

i'm using IIS 6.0 and PHP 5.2.11

If you are gettin the following error:

"Fatal error: session_start(): Failed to initialize storage module: files (path: ) in...."


Make sure that you have setup the session save path in your php.ini:

session.save_path = "/tmp"

which seems to be disabled by default.

I still have this problem, when i use php5.3.6 and phpmyadmin3.4.3.1.
And i have changed the php.ini session.save_path configuration to  "/tmp"
.

Hi, I know this problem refers to FreeBSD minor to version 5.x and PHP minor to version 5.x, but I want you guys to know that I solved this problem on FreeBSD 8.0 Release by uncommenting in your php.ini file:
session.save_path = "/tmp"

Here I'm PAMP user,
I am getting it everywhere, from PhpMyAdmin to E107...
whenever calls to session_start()

Fatal Error: function session start [<a href='function.session.start'>] Failed to initialize storage module user (C:\xxx\temp) on setup.php on line 82

But same is working on my hosting with exactly same php, mysql and apache version running

Apache 2.2.2 DAV/2 PHP 5.2.2 ZEND 2.2.0

I think only with Apache it has been seen