Description:
------------
After migrating web server platform from win2000 to freebsd periodicly
this message appears in logs:

PHP Fatal error: session_start(): Failed to initialize storage module.
in index.php on line 5
PHP Warning: Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line 0

I'm using now FreeBSD 4.8 and Apache 2.0.47

On the line 5 in index.php just a call session_start();

here's part of my config in php.ini:

session.auto_start Off
session.bug_compat_42 On
session.bug_compat_warn On
session.cache_expire 180
session.cache_limiter nocache
session.cookie_lifetime 0
session.cookie_path /
session.cookie_secure Off
session.entropy_length 0
session.gc_divisor 100
session.gc_maxlifetime 1440
session.gc_probability 1
session.name PHPSESSID
session.save_handler files
session.save_path /tmp
session.serialize_handler php
session.use_cookies On
session.use_only_cookies Off
session.use_trans_sid On

Reproduce code:
---------------
<?php

session_start();
session_register("m");

Expected result:
----------------
not to see this message in logs, see the page expected

Actual result:
--------------
PHP Fatal error: session_start(): Failed to initialize storage module.
in index.php on line 5
PHP Warning: Unknown(): A session is active. You cannot change the
session module's ini settings at this time. in Unknown on line 0

and we get just a blank page instead of seeing of what actually
expected

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