hi there,

i have a webserver running rh7.3 with apache 1.3.26 and php4.2.1 as
module. At random (not reproduceable reasons) all my session data gets
lost. the session file exists but all data written there in previous
scripts is gone.

All i get a hundreds of errors in my logfiles (like these):

[21-Aug-2002 16:47:07] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:47:13] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:48:29] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:48:51] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:49:49] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:50:04] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:50:19] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:52:02] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:52:11] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0

the webserver is at a very high load (70k users per day). problem is
that i need that session data but i cannot rely on them.

the session info in php.ini looks like this:

[snip]

[Session]
; Handler used to store/retrieve data.
session.save_handler = files

; Argument passed to save_handler.  In the case of files, this is the
path
; where data files are stored. Note: Windows users have to change this 
; variable in order to use PHP's session functions.
session.save_path = /tmp

; Whether to use cookies.
session.use_cookies = 1

; Name of the session (used as cookie name).
session.name = reqid

; Initialize session on request startup.
session.auto_start = 1

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 604800

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain =

; Handler used to serialize data.  php is the standard serializer of
PHP.
session.serialize_handler = php

; Percentual probability that the 'garbage collection' process is
started
; on every session initialization.
session.gc_probability = 1

; After this number of seconds, stored data will be seen as 'garbage'
and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; Check HTTP Referer to invalidate externally stored URLs containing
ids.
session.referer_check =

; How many bytes to read from the file.
session.entropy_length = 0

; Specified here to create the session id.
session.entropy_file =

;session.entropy_length = 16

;session.entropy_file = /dev/urandom

; Set to {nocache,private,public} to determine HTTP caching aspects.
session.cache_limiter = nocache

; Document expires after n minutes.
session.cache_expire = 180

; use transient sid support if enabled by compiling with
--enable-trans-sid.
session.use_trans_sid = 0

url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"

hi there,

i have a webserver running rh7.3 with apache 1.3.26 and php4.2.1 as
module. At random (not reproduceable reasons) all my session data gets
lost. the session file exists but all data written there in previous
scripts is gone.

All i get a hundreds of errors in my logfiles (like these):

[21-Aug-2002 16:47:07] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:47:13] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:48:29] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:48:51] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:49:49] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:50:04] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:50:19] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:52:02] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0
[21-Aug-2002 16:52:11] PHP Warning:  Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0

the webserver is at a very high load (70k users per day). problem is
that i need that session data but i cannot rely on them.

the session info in php.ini looks like this:

[snip]

[Session]
; Handler used to store/retrieve data.
session.save_handler = files

; Argument passed to save_handler.  In the case of files, this is the
path
; where data files are stored. Note: Windows users have to change this 
; variable in order to use PHP's session functions.
session.save_path = /tmp

; Whether to use cookies.
session.use_cookies = 1

; Name of the session (used as cookie name).
session.name = reqid

; Initialize session on request startup.
session.auto_start = 1

; Lifetime in seconds of cookie or, if 0, until browser is restarted.
session.cookie_lifetime = 604800

; The path for which the cookie is valid.
session.cookie_path = /

; The domain for which the cookie is valid.
session.cookie_domain =

; Handler used to serialize data.  php is the standard serializer of
PHP.
session.serialize_handler = php

; Percentual probability that the 'garbage collection' process is
started
; on every session initialization.
session.gc_probability = 1

; After this number of seconds, stored data will be seen as 'garbage'
and
; cleaned up by the garbage collection process.
session.gc_maxlifetime = 1440

; Check HTTP Referer to invalidate externally stored URLs containing
ids.
session.referer_check =

; How many bytes to read from the file.
session.entropy_length = 0

; Specified here to create the session id.
session.entropy_file =

;session.entropy_length = 16

;session.entropy_file = /dev/urandom

; Set to {nocache,private,public} to determine HTTP caching aspects.
session.cache_limiter = nocache

; Document expires after n minutes.
session.cache_expire = 180

; use transient sid support if enabled by compiling with
--enable-trans-sid.
session.use_trans_sid = 0

url_rewriter.tags =
"a=href,area=href,frame=src,input=src,form=fakeentry"

Maybe there's not enough space at /tmp.
Probably not a bug in PHP. 

sorry, no. (believe me i wouldnt post here if i could find any reasons
why my OS/Fs should screw up the files)

FYI I have tried LOTS of stuff but this problem persists.

[root@web1 root]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda5             49533868  19648360  27369332  42% /
/dev/hda1                23302      1348     20751   7% /boot
none                    514452         0    514452   0% /dev/shm
/dev/hda2              9288792     78404   8738480   1% /var

/tmp is in / and have 27gig free space, should be enough.

and as i said it doesnt lose all session data .. just a random (but too
high) portion.

upgraded to 4.2.2 today .. still the same errors

my configure:

./configure \
--with-apache=../apache_1.3.26 \
--with-pgsql=/opt/postgresql-7.2.1

kernel is 2.4.7-10, register_globals=On

.

hi,

problem solved.

still a bug in php.

I was using "register_shutdown_function" to dump some info to a logfile.
somehow it breaks the save_handler from session mod files. I removed the
shutdown function and put the line into an auto append php file. Now my
logfile is clean and by now i didnt get any strange session problems.

Hi,

I've been having the same problem that you have been experiencing. You
added a comment to my submission last week (Bug #19029) to setup error
logging.

I enabled the error logging after reading your post and I haven't been
getting any or the errors that you have been getting but our users are
still being logged out of the site.

We are not using the "register_shutdown_function" which would explain
why I haven't been getting the same error logs that you have been
getting.

PHP is running as the CGI version with Apache/1.3.19 (Unix) and the site
has FrontPage/5.0.2.2510 extensions.

hi,

i have randomly the same problems.
I have a Apache/1.3.26 with PHP Version 4.2.3-dev (23.8.2002)
somebody reported that you can workaround this Problem with an
shutdown_function wich makes an session_write_close but this is not the
case as you see in the error_log; this is bugkiller.php The opposite way
like reported here has no effect because before i had no
register_shutdown_function.

my error Log:
[Tue Aug 27 08:47:12 2002] [error] PHP Warning:  Failed to write session
data (files). Please verify that the current setting of
session.save_path is correct (/tmp/) in /[...]/bugkiller.php on line 5

my php ini is standard.

hi,

the problem returned. it doesnt seem to be affected by
register_shutdown_function. the day i thought the problem was gone was
related to a problem at our ISP (which caused very low traffic (5k
instead of 70k users))

maybe its just a problem under high load or something like that. im back
at the old problem (tried apache+php rpm (with dso), same problem).

Rather than have it in the log file which it probably registers in as
well, I have the message displaying on my ecommerce site just after the
session crashes into oblivion losing all cart items and user log-in
data.

This is EXTREMELY URGENT as My clients are pissed at me.

How the hell do i workround this ????
What the hells causing it???

I suspect that it has something to do with the level of depth that is
utilised in a require_once stack... eg if a require once calls a page
that issues a require once or include which calls a page that issues
another require once... etc...  At some point the server gets lost as to
where the session cache is being written to and goes belly up

Further to this I have since discovered that the server generated
PHPSESSID=713540145172t2t0 addon to links genereated on these pages
where the Warning occurs are generated as follows...

https://www.aussiepharmacy.com.au/index3.php?pid=46&cart_action=Add&PHPS
ESSID=<?php session_id(); ?>

which is not much use either.

Unfortunately I cannot reproduce this locally here, and looking the code
I don't see anything particularly/glaringly wrong.

The piece of code in question (I believe) is the
php_session_save_state() function, most specifically the PS(mod)->write
pieces of code.  

Does this happen on a non-loaded system as well?  Would any of you be
willing to apply some patches to see if things do and do not work?

Hi there,

We didn't run into this problem until the site that we were working on
went live and we have been unable to replicate the problem on our dev
server in our office. 

So I'm guessing that the bug only appears on a loaded system.

Cheers, Ross

Your production server wouldn't happen to have multiple cpus?

I'm not sure since we don't host the production site we are just the
developers. When I do a uname I get this:

Linux lsh129.siteprotect.com 2.4.18-pre7 #5 SMP Mon Feb 4 17:42:59 CST
2002 i686 unknown

I'm guessing that the SMP bit means that the server is using multiple
processors, but I'm not sure.

Yup, the SMP means it likely has multiple processors.  "cat
/proc/cpuinfo" would tell you for sure.  A nasty bug was fixed recently
which only affected SMP machines and would cause exactly these symptoms.
 4.2.3 will have the fix.

hi there,

as far as i can tell the problem only appears if the server runs on
middle to high load. (eg. >100httpd)

the problem machine is a p4-1,8ghz with 1gig ram (no smp) and we couldnt
yet reproduce the problem on any other server. the machine only runs the
httpd, postgres is running on a different machine. its using a IDE hd
(some special scsi or something)

i'm willing to apply some patches to get rid of the problem. i looked
into the problem myself but couldn't find any problem in PS(mod)->write
or the resulting write to the hd (which i guess is
PS_WRITE_FUNC(files)). I never coded on linux neither much of c (only
c++, c#, java) but maybe p/write does have a problem.

#ifdef HAVE_PWRITE  
        n = pwrite(data->fd, val, vallen, 0);
#else                   
        lseek(data->fd, 0, SEEK_SET);
        n = write(data->fd, val, vallen);
#endif

anyways, send me some patches via email and i'll try my best to find a
workarround.

greets,
thomas

Yes actually the PREAD functionality in the glibc has been found to be
buggy (this is actually in another bug report as well, I just forget the
number off hand).  It was fixed in the CVS for glibc, but that was only
as of July 2002.  

Regardless, try a snapshot for HEAD dated sometime after this point,
I've taken the PREAD out again.  Post back results.  

Our client just pulled out and i lost my job due to this bug. Thanks
guys

Shane: please read the following:
http://www.php.net/license/3_0.txt (particularly the part
in uppercase).

Then read this:
http://www.derickrethans.nl/20020502.php.

lol - I dont care anymore mate - just fix it and im happy

Then shush up and test a snapshot please :)

Trying snapshots isn't an option on production servers..

hi,

sorry been quite busy lately. I upgraded to php4.2.3 today .. still the
same problem. I hope i'll have some time to test a actual snapshot
today/tommorrow.

testing on production server sucks, but the problem itself is even
worse.

stay tuned,
thomas

Please try using this CVS snapshot:

  http://snaps.php.net/php4-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-latest.zip

No feedback was provided for this bug for over a month, 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".

Hello,
I am also experiencing this bug.  I am using Debian, 2.4.18 kernel, SMP
machine, PHP 4.2.3. (also observed bug on PHP 4.1.2).  The server is not
experiencing a heavy load.

I am attempting to script a temporary fix for this bug until there is a
permanent fix in a stable PHP release.  Would something like the
following work?

1. At the end of every page request, backup the session file:

copy(session_save_path() . '/sess_' . session_id(), 
    session_save_path() . '/sess_' . session_id() . '_bak');

2. At the top of each script that requires session data, check to see if
the main session file has been truncated.  If so, replace it with the
backup that you have created.  Assuming you have the session Id stored
in a cookie as 'user_sess_id':

if (isset($_COOKIE[user_sess_id])
    && file_exists(session_save_path() . '/sess_' .
$_COOKIE[user_sess_id] . '_bak')
    && file_exists(session_save_path() . '/sess_' .
$_COOKIE[user_sess_id]) && (filesize(session_save_path() . '/sess_' .
$_COOKIE[user_sess_id]) == 0)
    && (filesize(session_save_path() . '/sess_' . $_COOKIE[user_sess_id]
. '_bak') > 0) ) {
    // restore the session file
    copy(session_save_path() . '/sess_' . $_COOKIE[user_sess_id] .
'_bak', session_save_path() . '/sess_' . $_COOKIE[user_sess_id]);
}
// continue with script...

Does this have any hope of helping restore the lost session data?  Or
would PHP have already read in the session data from the file on disk
before it reaches this point of processing the code?

Any advice on how PHP coders can write a temporary fix for this bug
would be greatly appreciated.
Thanks,
Taylor Davis

I'm experiencing this too, and I might have some usefull feedback!

I don't see the 'failed to write' messages. But I do have the random
loss of sessions. I've modified my script so I get an email with all
GET_VARS, SERVER_VARS etc. whenever the sessiondata is lost.

I found a very weird thing with respect to the session cookie. It
contained:

HTTP_COOKIE          = 1; PHPSESSID=f1faf3374d562e8738f64e7e7e030972;
pollvoted[1]=1;  (... some other data left out for privacy reasons);
PHPSESSID=842be4994a9c424fd7d4f9f8049aadc9

There are two separate PHPSESSID's in the same cookie! Maybe one of the
too is indeed invalid (no session date) How is this possible?

I got this too and its on a low traffic dev server.  This 
started happening even with old sites.  I use FreeBSD and 
the latest of everything.  I will not upgrade the PHP on my 
prod servers until this is resolved.  good luck.

I've seen this bug on FreeBSD since PHP4.0.* series. Now I use 4.2.2. It
happens rarely. I could not figure why - the probability is small.

Another data point. I've recently moved a system from a hosted server
running 4.06 to a server under my control running redhat 7.3 and php
4.2.3 Since the move I've been getting very occasional cases of users
logging in and receiving someone else's session. The session handling is
very simple.

On login 
  session_name($db_name);
  session_start();
  $user = new User($userid, $passwd);
  session_register("user");

On return
  session_name($db_name);
  session_start();

I've tried various workarounds like 
  session.entropy_length    = 512
  session.entropy_file      = /dev/urandom
in the belief that somehow the two people were getting the same ID and
hence temp file

But all this was just thrashing at the problem. Then I checked my own
cookies and discovered the same as 
ivo@ibuildings.nl The cookie contained two session IDs. So I deleted all
relevant cookies. Logged out and in and now I'm back to the expected
single ID in the cookie. 

I have logging turned on but have not yet seen any errors.

I receive this bug too...I have traced it back to breaking as soon as I
use session_id(); function, and then working fine again once use of that
function is removed.

Okay, I think I solved this bug for me at least.

I would receive this error:

Failed to write session data (files). Please verify that the current
setting of session.save_path is correct (c:\windows\temp) in Unknown on
line 0

and I finally tracked it down to being I was sometimes setting the
session_id(""); to blank, aka, to nothing. That would cause it to fail.
I still think this is a bug, because you shouldn't be able to break it
by setting it to nothing.

The reason I was unable to track this down quicker was because I had no
idea I was passing a blank variable to the session_id. So I looked into
that, and it turns out PHP fails to delete cookies.

I think their is a bug with the delete cookie functions...you might want
to check into that. To solve this, instead of deleting the cookies, I
just set them to -1, and then checked if they were -1, and if so,
treated them as if they weren't there.

I hope this helps,
Nate

You can work around this bug by changing the session saver to "mm"
(without the quotes).

There are no known solutions to this problem that I can see out there.
The only people with solutions are the windows people who didn't change
the php.ini file to have a windows path in it. FOr the Linux people,
this may well be a library compatibility problem, which is the best
guess so far but is probably wrong!

Hello, had the same error on a low-traffice development server (one
processor) with pretty standart php (4.2.3) + apache (1.3.26) set-up. I
noticed that I forgot the SID on one page and that somehow messed up the
session and created the error on all pages that tried to access this
same session. After I put the missing SID in, everything worked fine...

ALL READ THIS PLEASE !!! SOLUTION TO
Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0

In this case an many other, working with Linux or FreeBSD, remember that
applications are users too. I am not an expert on this OS, but I know
something. When a user does not have a home directory, he can not do a
lot of things, among them is to execute many commands (why? do not ask)
you may check, create a user with no home dir and test. So that is the
problem with mysql and www, (PHP is working as www because apache), SO,
assign a home dir to www and you will see the error no more. The same
may happen with some mysql change settings. Thanks.

my apache is running as "nobody,nogroup" with an assigned homedir of "/"
or "/tmp" or "/dev/null" or "/var".

the error still spams my logfiles, but alot less cause i have migrated
over to java/jsp. seems like the only way to fix this is to redruce
traffic.

I have a basic installation of OpenBSD 3.2, Qmail 1.03, Courier-IMAP
1.6.2, Apache 1.3.26, PHP 4.2.3. I have configured PHP and all seems
run. But, when I installed SquirrelMail 1.2.10 for webmail service, I
received the same error

Warning: open(/tmp/sess_7538b7739bdd44e2fb0e747f65af858d, O_RDWR)
failed: No such file or directory (2) in /htdocs/webmail/src/global.php
on line 134

and then

Warning: Failed to write session data (files). Please verify that the
current setting of session.save_path is correct (/tmp) in Unknown on
line 0

I think it is your same problem. I have also tried to write a simple php
file with only the row

<? session_open(); ?>

It returns the usual error! I hope there will be a solution as soon as
possible, I'm very sad to see all run but I can't install my Squirrel
WebMail...

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

(can not reproduce anywhere)

I HAVE SOLVED!!!

I created a tmp directory in /var/www that is my OpenBSD Apache root
directory (not document root). I set the right permissions and now it
runs!!!

Good luck guys!

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

I was having similar problems. It seems to be related to the require()
statement. 
I solved this putting the seesion_start() statement outside the included
script (e.g. if I have require("auth.php") I put session_start() issue
outside auth.php.
At least It works in my particular case. You can test it and see if it
works for you too.
Please post your results. I

I have had this problem for a long time.

Thanks to the individual that mentioned the /var/www/tmp directory.  I
did not change the permissions of the directory, I simply got rid of it
and the problem went away.

I used to have a /var/www/tmp from testing in the past.  So I just
deleted it and the problem is solved.

PHP developers:  Any reason why this would mess up PHP sessions?

I am also having this problem, FreeBSD 4.6.2 with
Apache/1.3.27 (Unix) mod_throttle/3.1.2 mod_gzip/1.3.19.1a PHP/4.2.3

Using SquirrelMail 1.4.0 I get the usual:

Failed to write session data
(files). Please verify that the current setting of session.save_path is
correct (/tmp) in Unknown on line 0

My box has multiple CPUs.

Scratch my last post.  The problem is back again.  I'm having this issue
with PHP 4.2.3 and apache 1.3.27 with SSL.  I do have luck when
restarting apache sometimes.  I'm not 100% positive, but it often fixes
itself after I restart my normal apache NOT my apache-ssl which is
running my webmail site (horde) that breaks due to this bug.

For the record, I also have 2 CPUs since that seems to be a common
trend.  The load is very low.

(/tmp/sess_7538b7739bdd44e2fb0e747f65af858d, O_RDWR) is this a problem
???  NO

create a tmp folder in your SERVER ROOT like /var/www/tmp

and it will work fine 

php.ini means not the / php means the WebServer Root

For the people not experiencing the "failed to write session data" error
but those of you that do experience the 'random lose of session data'
here a possible solution:

Check if your script uses cookies AND sessions in one script.
Comment all the 'setcookie' lines and all other cookie functions in your
script and check if your problem still exists...

It solved the problem ("dissapearing sessions causing users to log out")
for me.

hello palls,

i hope my workaround might help.
i have experienced the same failure on a debian woody dev server with no
load running a pentium 100 mhz with php 4.1.2. i had the problem on a
page which was calling session_id() with no parameters.
after reading this list, i have changed the first call to session_id()
to: session_id(session_id("a")) and the problem dissapeared. i must
mention that after the first time i found the problem, it didn't stop
until this workaround.
although i didn't examine php source, it might be that the solution for
this case would be checking the number of parameters to session_id().
thank you very much for your work and contributions.

alex

it's me again.
i must mention that the problem occured to me on the index.php page,
where i was calling session_id() after session_start(). (here is the
place the id should be created for the first time). it didn't appear on
pages that call  session_id($_GET[$_SESSION[session_name()]]) before
session_start().
thanks again,

alex

I was getting this error 100% of the time on a Debian installation
running PHP 4.1.2, with the following simple page:
<?
session_start();
phpinfo();
?>

It turns out that my php.ini file contained the following setting:
; Handler used to store/retrieve data.
;session.save_handler = files
session.save_handler = user

Changing this to:
; Handler used to store/retrieve data.
session.save_handler = files
;session.save_handler = user

fixed the problem.  Not a PHP expert, so this may be obvious.

Cheers

Hello guys,

i was also having the same problem, on a PIII~933Mhz,Windows .NET
Server, i changed my php.ini, and its now working fine.
-- Original/Default --
[Session]
; Handler used to store/retrieve data.
session.save_handler = Files

continued from above - 

here is the change i made to php.ini

[Session]
; Handler used to store/retrieve data.
;session.save_handler = files // old
session.save_handler = %TMP%

%TMP% is the default path for temporary storage on windows.

thanks
rajiv

I am working on a PII 350 dev machine.  
php 4.3.4/apache 2.0.48 
 
same problem  
used PEAR::Auth module and discoverd this bug. I can't seem to get 
rid of it. Tried all of the solutions presented on this site save from 
installing windows on my machine. I'm gonna try to recreate this bug 
on my laptop at work (winxp). See what happens there.

I was having the same problem, failed to write session data files, check
your save path error.  Worked fine in Netscape 7.1, but not in IE 6.  I
deleted my cookies, cleared history, deleted internet files, and
rebooted.  It worked like a charm after that.  I don't know how that
would affect it, but that's all I did... and like I say, it always
worked, everytime in Netscape 7.1.

I also have been receiving this error since Jan 1st, 2004. Running on
Linux operating system, Apache version 1.3.29 (Unix), PHP version 4.3.3

My error log is full of these errors:

PHP Warning:  Unknown(): Failed to write session data (files). Please
verify that the current setting of session.save_path is correct
(/usr/home/asdwq1/sessions) in Unknown on line 0

PHP Warning:  session_start(): The session id contains invalid
characters, valid characters are only a-z, A-Z and 0-9 in
/usr/home/asdwq1/public_html/index.php on line 2

Line 2 of index.php = session_start();

Strange thing is it only happens some of the time. I use SID throughout
so how can php create a session id and then say on the next page it is
an invalid session id? I don't quite understand how it can be invalid
when php creates this upon the call of the first session_start().

$_SESSION vars are only used and it occurs where-ever I move the session
temp directory to.

I was having the problem on OpenBSD 3.2, Apache 1.3.26, PHP 3.2.3 when
running phpBB. I deleted all my cookies and logged back in again and the
problem went.

I don't use cookies for handling sessions, I pass it in the URL. ie
session.use_trans_sid = 1

Just started to expience this after a shift to a new server.
php 4.3.3 on Debian Sarge

I get the error when I return to the site after logging out.

Looking at the cookie data the cookie data PHPSESSID is being set to
null, which my browser is recording in it's cookie database. Then on
return the site attempts to access informaiotn for PHPSESSID=(NULL)
which is what I think is causing the problem with this error.

Does anyone else see the same problem on their respective sites?

Stewart

After weeks of testing, I have fixed the problem at least for me.

The problem is the Zend Optimizer was corrupting/wiping (presumably) the
session data. Turning Zend Optimizer off completely fixed the problem.
When I turned Zend Optimizer back on and rebooted the session problem
was back again, this is the first reproducible action for me so far.

Would be interesting to know how many others with this problem have Zend
Optimizer running.

Experiencing the same problems here... out of the blue.  
Machine was running beautifully then all of a sudden it 
stopped.  No one can log in.  I changed nothing... there 
was not so much as a shell login on the machine for 30+ 
days.

sessions seem very fragile (as do many things in php 
lately, it's getting scarier to keep running in 
production environment).

[Fri Mar 26 16:14:04 2004] [error] PHP Warning:  Failed 
to write session data (files). Please verify that the 
current setting of session.save_path is correct (/
websites/sessions) in Unknown on line 0

I've done so far almost everything suggested that worked 
for others in here, none of it solved the problems.  I 
can tell you that:

1) it's NOT a permissions problem, my user running 
apache/php has full write access to /tmp
2) it's not required for this user to have a home 
directory.  For those that need to do this to 'fix' the 
problem, you OS is broken! (complain to your vendors)
3) it works for exactly one session.  The first login 
works fine and it seems that from there on in PHP tries 
to use the same session ID for everyone ?
4) manually deleting the existing session file allows on 
single login again after this.

Trying to track down more things. Really perplexing as 
to why/how it stopped working when it ran fine for a 8+ 
months.

Ok .. i got my setup working again .. an old bug that I 
had forgotten the workaround for

I added (right before my initial session_start()):

session_destroy();

This destroys (presumably) any previous sessions 
leftover after an older login.  Maybe a php bug?  Maybe 
a browser issue?  Maybe a bit of both?  (I have it set 
to not use cookies but yet it still does).

Perplexing, but hopefully this helps out others that 
might run into this issue.

I'm losing session variables randomly too. Sometimes I get the "Failed
to write..." error but not always.

Since I don't host my servers I can't give full server details. However
here's a test script on both servers with the relevant PHPInfo:

Server A: http://chir.ag/test.php
Server B: https://secure.magictanorders.com/test.php

Test script:

<?php

  session_cache_expire(30);
  session_start();

  if($_SESSION["test"] == 1)
  {
    echo "<center>Sessions work.</center><br><br>";
  }
  else
  {
    $_SESSION["test"] = 1;
    echo "<center>Starting Session... Click refresh to see if the
session works or not.</center><br><br>";
  }

  phpinfo();

?>

Basically Server A works ALWAYS and remembers the session for upto 30
minutes. Server B randomly forgets the session in 1 second to 5 minutes.
No session on Server B lasts more than 5 minutes.

The problem randomly started on Server B yesterday (Apr 1). We thought
it was output_buffering (and turned it ON) but that didn't help. Problem
was back this morning. The site was working perfectly for 3 weeks before
breaking down randomly. If anyone can give any suggestions I will be
very thankful.

Hi guys,

i experienced the same problem since 3 weeks.. my session dies after the
current request...

after some investigations:
php sends a wrong "Set-Cookie" header in the HTTP request.. maybe due to
the load.. i'm not sure
==================================================
GET / HTTP/1.0
Accept: */*
Referer: my_host
Accept-Language: fr-ch
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: my_host
Connection: Keep-Alive

HTTP/1.1 200 OK
Date: Sat, 03 Apr 2004 11:23:42 GMT
Server: Apache
X-Powered-By: PHP/4.3.3
Set-Cookie: PHPSESSID=50f49658391ab2bfd84ab11baf7b124c; expires=Tue,
23-Sep-1902 09:55:18 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html
==================================================

as you can see, the date is wrong .. i made my test today (4th April) ..
mmmh.. i wasn't born when the cookie died :)

i made a very straightforward workaround that is to backup the session
id and restore it as needed.. 

you can simply cut & paste the following code
<?
    // restore the backup cookie
    if (isset($_COOKIE["PHPSESSIDBK"])) {
        $_COOKIE["PHPSESSID"] = $_COOKIE["PHPSESSIDBK"];
    }
 
    // start the session as usual
    session_start();
 
    // create the backup if needed
    if (!isset($_COOKIE["PHPSESSIDBK"])) {
        header("Set-Cookie: PHPSESSIDBK=".session_id()); // you can add
the expiry date if you want
    } 
?>

i tried this and it works fine.. there's maybe some smarter to do.. but
that way it works..

i hope it will also help the php team to find out what happens... the
only reason i can see is server-load.. on my dev server it never
happened.. 

so .. let's go back to work :)

the sessions on my system sometimes look like this:

68.217.0.206.276341084854774671 

it's like the php isn't md5'ing the data or something to make the
session.  i would assume that maybe php is looking for file:
/tmp/sess_68.217.0.206.276341084854774671  instead of the
/tmp/sess_md5(68.217.0.206.276341084854774671 ) or base64 or whatever
php encodes the session to.  if i'm right about this, it wouldn't be
able to read the session because it's looking for another file cause
it's not encoding the session variable right... i get this in my apache
logs, which gets put in my sql database.  as i log the cookies in apache
logs, i had to reformat my sql tables to store 255 chars instead of
32... i need to know how to fix this.  it happens randomly and i can
only wait till it screws up so i can try to fix it... please email me if
you find a fix!!!! thanks =]

i have the same bug, however, it seems my windows xp box with ie6.0
handles it well, possibly because of the double cookie values being
handled properly?  i was using my site for a few months, wandering why
people weren't signing up, then i used my site on my living room
computer and got errors.  i have windows 2k and ie5 on it.  i get no
errors with netscape 7.0 or mozilla or firefox either.  so, if you ask
me: i don't use the php pear rep for the same reason that I'm about to
code my own class for handling sessions.  i hate managing a large code
repository of my own, but the only thing that annoys me more is not
understanding what is wrong because of some strange error.

I just started encountering this problem today, after having upgraded to
PHP5 from a PHP4 app. As with some of the other reports I have some
users reporting constant problems, while others have no problems at
all.

I using Linux, with session files written to /tmp. I can see that many
session files are being written, but at the same time some session calls
produce errors. I do not use any session function in my code other than
session_start()

I have been experiencing the same (or very similar) problem. One
interesting thing that I found is that sometimes I can reload page A and
see the session data happily sitting there, but on page B the data is
not there. I have both pages open in tabs in Firefox and I can go back
and forth reloading the pages. Page A always has the data, page B never
does. Both pages require the same init.php script to start the session.

I have been getting the same error...

in php.ini file i have set the session.save_path to
public_html/cgi-bin/session

And the chmod of the session folder is 777

Everything looks fine technically but even if that... i get this error.

I really need help to figure out this issue and fix it. And the hosting
company that i work with they insist on saying that it is not a server
error. But I do not understand that even if the chomod of the
session.save_path pointing to the correct folder and chmod 777, I am
getting this error.

PHP Warning:  session_start() [<a
href='function.session-start'>function.session-staPHP Warning: 
session_start() [<a
href='function.session-start'>function.session-start</a>]:
open(/home/users/web/b469/as.xxxxx/sess_164a72ebe9813cc1b0341ad6f6edbc8a
, O_RDWR) failed: Read-only file system (30) in
/hermes/web03/b469/as.xxxx/public_html/admin/index.php on line 31
PHP Warning:  Unknown(): Failed to write session data (files). Please
verify that the current setting of session.save_path is correct
(/home/users/web/b469/as.yuvamemlak/public_html/cgi-bin/session) in
Unknown on line 0

thank you in advance

I too am getting similar messages - essentially where the session file
is failing to create.  Unfortunately I am getting it all the time, which
is a problem as I am trying to teach myself PHP at home.

What is different for me is that I am running a Windows 2K server, using
IIS, and PHP 5.2.2.

The initial error I get at the first session_start() call is:
The description for Event ID ( 2 ) in Source ( PHP-5.2.2 ) cannot be
found. The local computer may not have the necessary registry
information or message DLL files to display messages from a remote
computer. The following information is part of the event: php[352], PHP
Warning:  session_start() [<a
href='function.session-start'>function.session-start</a>]:
open(\tmp\sess_8t6afg6omu4au9ofqnru80l6r5, O_RDWR) failed: No such file
or directory (2) in F:\MixWeb\mdroot\php_sandpit\ch10\login.php on line
60.

The extract of my php.ini is:
[Session]

session.save_handler = files

session.save_path = "0;\tmp"

session.use_cookies = 1
session.name = PHPSESSID
session.auto_start = 0
session.cookie_lifetime = 0
session.cookie_path = /

Having been trying to search down answers for this but so far no luck.

session.save_path = "0;\tmp"

??  What is 0;\tmp supposed to mean?

We are currently getting the same error on 2 different enviroments. This
does not happen all the time, but often enough to be an annoyance during
testing.

Environment as follows:
1. FreeBSD 6.2-RELEASE 
[root@crossbow /]# cat /usr/local/etc/php.ini | grep "session"

session.save_handler = files
session.save_path = "/var/tmp"
session.use_cookies = 1

[root@crossbow /]# php -v
PHP 5.2.9 with Suhosin-Patch 0.9.7 (cli) (built: Mar 31 2009 12:24:17) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
[root@crossbow /var/www/branches]# apachectl -v
Server version: Apache/2.0.63
Server built:   Apr 16 2008 16:52:47

---
2. Red Hat Enterprise Linux ES 4

[root@131080-stagingdb /]# cat /etc/php.ini |grep "session"
session.save_handler = files
session.save_path = "/var/lib/php/session"
session.use_cookies = 1

[root@131080-stagingdb /]# php -v
PHP 5.2.9 (cli) (built: Feb 27 2009 14:38:59) 
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
[root@131080-stagingdb logs]# apachectl -v
Server version: Apache/2.0.52
Server built:   Jun 29 2007 05:07:13