|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27963 Default Session Values lost after explictly set for a given httpd process
Submitted: 2004-04-12 10:37 UTC Modified: 2004-04-13 14:25 UTC
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: joobri at sas dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4CVS, 5CVS (2004-04-13) OS: *
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: joobri at sas dot com
New email:
PHP Version: OS:


 [2004-04-12 10:37 UTC] joobri at sas dot com
When PHP code is run that explicitly sets (and overrides) the default value of session_module_name, subsequent requests to that httpd process use the value that was set and do not default back to the default value.  This causes intermittant problems on our web server running 300 httpd processes - some apache processes have the default value and some have a different value if they were set by code run on that process.

In the cases where it fails, the session module name
is not the configured default of "files" but is "user" instead.  It looks like
in some circumstances an alternate session module is "left-over" from a previous
request.  (I've seen similar "left-overs" with other configuration directives,
notably error log level, in the past.)

The work-around we are using: add an explicit
before calling any other session-related functions.

The following 2 errors are in the log:

/nfs/swwprod2/local/etc/httpd.dir/logs/error_log:[Thu Apr  8 09:23:18 2004]
[error] PHP Fatal error:  session_start() [<a
Failed to initialize storage module: user (path: /tmp) in
/remote/tappan/vol/vol4/tools/testhelp/websrc/existing.php on line 3
/nfs/swwprod2/local/etc/httpd.dir/logs/error_log:[Thu Apr  8 09:23:33 2004]
[error] PHP Fatal error:  session_start() [<a
Failed to initialize storage module: user (path: /tmp) in
/remote/tappan/vol/vol4/tools/testhelp/websrc/existing.php on line 3

Reproduce code:
Default Value: session_module_name("files");

In your code, specify session_module_name("user");

Set your apache server to run with only one httpd process - run your code setting session_module_name to user.

Subsequent requests by a page not setting the session_module_name value will have the session_module_name set to user and not default back to files.

Expected result:
When you don't specify session_module_name it should set back to the default value.

Actual result:
session_module_name retains the last value set, not the default value.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-04-13 14:25 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

 [2004-06-15 15:05 UTC] datacompboy at mail dot ru
Looks like problem still.

Currently runned workaround via
auto_prepend_file       = /etc/httpd/phpinc.php

and in /etc/httpd/phpinc.php
<? session_module_name("files"); ?>
 [2004-08-23 20:01 UTC] Daniel dot Lindenberger at swivel dot net
On our system running 4.3.4, it seems to alternate between using "files" and "user", despite the fact that it's defined as "files" in php.ini, and is never set with session_module_name to "user". 

It was running fine for at least three months before the issue started last week, when we started testing uploading extremely large files through. We changed post_max_size and upload_max_filesize to 250M, though I don't know how this could effect it.

We're only running around 10-20 apache processes at a time

We receive the message:
Fatal error: session_start(): Failed to initialize storage module.

When it is set to "user".

This may be fixed in subsequent versions, but was different enough from Joobri's description that I thought I would mention it.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Thu May 28 08:01:25 2020 UTC