|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25876 session_start(): Failed to initialize storage module
Submitted: 2003-10-15 07:03 UTC Modified: 2007-09-13 01:00 UTC
Avg. Score:4.5 ± 0.7
Reproduced:379 of 383 (99.0%)
Same Version:116 (30.6%)
Same OS:159 (42.0%)
From: golden at riscom dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.3.9-4.3.10 OS: freebsd 4.8
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: golden at riscom dot com
New email:
PHP Version: OS:


 [2003-10-15 07:03 UTC] golden at riscom dot com
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 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:


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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-10-16 22:34 UTC]
Is the /tmp directory writeable by the web server and is there avaliable space in there?
 [2003-10-17 04:37 UTC] golden at riscom dot com
-bash-2.05b$ ls -l
drwxrwxrwt   4 root  wheel     2048 Oct 17 11:37 tmp
 [2003-10-17 04:39 UTC] golden at riscom dot com
/tmp is not a separate partition
/dev/da0s1a   4.7G   133M   4.2G     3%    /
 [2005-03-18 10:02 UTC]
See bug #32330 for similar issue. Do you use session_destroy() anywhere? Or session_decode()? 

 [2005-03-28 19:27 UTC] clix at theclixnetwork dot com
A client of mine is having the same problem. The script uses:


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.
 [2005-03-31 03:00 UTC] james at westcoastbmx dot com
i have this problem as well.

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


will not work.
 [2005-04-02 16:21 UTC] tj at tjshafer dot com
I am also having this problem

Freebsd 4.8
php 4.3.10
 [2005-04-08 19:03 UTC] todd dot trann at palidar dot com
RedHat 9
PHP 4.3.9 from RPM (
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.

 [2005-04-29 11:04 UTC] dmih at in-solve dot ru
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.
 [2005-05-17 18:00 UTC] jspec at bellsouth dot net
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!?
 [2005-05-18 22:48 UTC] dmih at in-solve dot ru
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 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.
 [2005-05-21 01:24 UTC] jspec at bellsouth dot net
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?
 [2005-05-21 14:30 UTC] gul_murjani at yahoo dot com

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:

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.

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

Here's the rundown on each site:
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

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

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

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

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.


 [2005-05-22 12:06 UTC] dmih at in-solve dot ru
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?
 [2005-06-08 14:18 UTC] tech at c64-wiki dot de
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 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
 [2005-06-08 14:58 UTC] tech at c64-wiki dot de
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
 [2005-06-18 11:03 UTC] guillaume at ironie dot org
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
 [2005-06-27 10:37 UTC] ftownes at w3-hosting dot net
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 
if (ini_get("session.save_handler") == "user") {

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:

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.
 [2005-08-15 11:04 UTC] frank dot altpeter at gmail dot com
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.
 [2005-08-18 10:15 UTC] frank dot altpeter at gmail dot com
Used the workaround mentioned two comments below, but experiencing still the same sporadic errors.

Any further hints are very appreciated.
 [2005-08-26 07:11 UTC] smbukas at gmail dot com
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
 [2005-09-08 01:42 UTC] info at ruudgoedhart dot nl
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
 [2005-09-30 20:32 UTC] dan at nitro dot com
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:
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!
 [2005-10-30 16:11 UTC] support3 at futurahost dot com

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.
 [2005-12-02 13:11 UTC] ts at dreamcoder dot dk
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.
 [2005-12-08 07:59 UTC] henmarrina at gmail dot com
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 any concrete solution for this problem
 [2005-12-20 18:06 UTC] siggi at junesystems dot com
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.
 [2006-02-15 14:43 UTC] jjohanso at online dot no
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...
 [2006-03-03 22:40 UTC] s at guerril dot nnoosppaamm dot la
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.
 [2006-03-05 04:51 UTC] rsalsa at gmail dot com
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.
 [2006-03-28 13:45 UTC] stjernstrom at gmail dot com
We have this problem to.

Nothing helps :(
 [2006-06-27 06:28 UTC] hmahmoud1900 at gmail dot com
still have same problem , user session empty and get out of the site.
try all what the guys said , nothing happened
 [2006-07-21 08:05 UTC] contact at far-php dot ro
i have this problem as well.

PHP version 4.3.11

Script index.php:

/tmp -> /domanin_site/tmp/
 [2006-12-09 20:02 UTC] thecancerus at gmail dot com
we can pass session id to ensuser that session remains intact.. use SID it will help
 [2007-02-03 16:51 UTC] earnie at users dot sourceforge dot net
Just to note: This error happens if the functions identified in session_set_save_handler are not defined at the time of the call.
 [2007-06-27 23:15 UTC] josh at spinningplanet dot co dot nz
Try disabling safe mode
 [2007-08-30 07:54 UTC] golden at riscom dot com
> We are currently having problem with the same think at one of our servers.
 [2007-09-05 13:51 UTC]
Can your reproduce this with PHP 5.2.4 or greater? (in case we happen to release 5.2.5 in the meantime :)
 [2007-09-13 01:00 UTC] php-bugs at lists dot php dot net
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".
 [2008-02-16 11:11 UTC] notrevevirtual at gmail dot com
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.
 [2008-04-02 06:37 UTC] webmaster at mindrabbit dot com
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.

 [2008-06-23 15:07 UTC] james at dunmore dot me dot uk
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;


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.


Problem sovled  - well, it's not, session_destroy should not destroy the save handler
 [2009-11-05 13:32 UTC] gonzalo4 at gmail dot com
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
 [2011-03-03 12:18 UTC] comments at htmlcompressor dot com
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.
 [2011-07-12 03:19 UTC] shappen at gmail dot com
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"
 [2011-08-12 12:58 UTC] okasion at gmail dot com
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"
 [2012-03-30 00:34 UTC] ronniebasak22 at rediffmail dot com
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
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Mar 21 02:03:42 2023 UTC