php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19022 PHP Warning: Failed to write session data (files)
Submitted: 2002-08-21 11:09 UTC Modified: 2008-02-28 17:50 UTC
Votes:241
Avg. Score:4.3 ± 0.9
Reproduced:183 of 195 (93.8%)
Same Version:52 (28.4%)
Same OS:64 (35.0%)
From: phpbugs at mx4k dot com Assigned:
Status: No Feedback Package: Session related
PHP Version: 4.2.2 OS: linux (rh7.3), apache 1.3.26
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2002-08-21 11:09 UTC] phpbugs at mx4k dot com
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"

Patches

tmp (last revision 2010-05-30 00:32 UTC by thanhdiavn at yahoo dot com dot vn)

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-08-21 11:14 UTC] phpbugs at mx4k dot com
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"
 [2002-08-21 13:33 UTC] sander@php.net
Maybe there's not enough space at /tmp.
Probably not a bug in PHP. 
 [2002-08-21 18:51 UTC] phpbugs at mx4k dot com
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.
 [2002-08-22 07:10 UTC] phpbugs at mx4k dot com
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
 [2002-08-22 07:16 UTC] phpbugs at mx4k dot com
.
 [2002-08-23 06:15 UTC] phpbugs at mx4k dot com
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.
 [2002-08-25 20:21 UTC] rossr at reactive dot com
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.
 [2002-08-27 03:22 UTC] m dot heidenwolf at ehotel dot ag
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.
 [2002-08-27 06:08 UTC] phpbugs at mx4k dot com
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).
 [2002-09-03 23:08 UTC] ShaneO at alldigitalservices dot com dot au
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
 [2002-09-03 23:35 UTC] ShaneO at alldigitalservices dot com dot au
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&PHPSESSID=<?php session_id(); ?>

which is not much use either.
 [2002-09-03 23:46 UTC] kalowsky@php.net
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?
 [2002-09-04 00:06 UTC] rossr at reactive dot com
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
 [2002-09-04 00:29 UTC] rasmus@php.net
Your production server wouldn't happen to have multiple cpus?
 [2002-09-04 00:43 UTC] rossr at reactive dot com
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.
 [2002-09-04 00:47 UTC] rasmus@php.net
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.
 [2002-09-04 06:35 UTC] phpbugs at mx4k dot com
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
 [2002-09-04 08:41 UTC] kalowsky@php.net
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.  
 [2002-09-04 18:47 UTC] ShaneO at alldigitalservices dot com dot au
Our client just pulled out and i lost my job due to this bug. Thanks guys
 [2002-09-04 19:11 UTC] wez@php.net
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.

 [2002-09-04 22:57 UTC] ShaneO at alldigitalservices dot com dot au
lol - I dont care anymore mate - just fix it and im happy
 [2002-09-04 23:22 UTC] kalowsky@php.net
Then shush up and test a snapshot please :)
 [2002-09-06 04:39 UTC] kivi at picox dot se
Trying snapshots isn't an option on production servers..
 [2002-09-18 06:52 UTC] phpbugs at mx4k dot com
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
 [2002-09-26 12:08 UTC] sniper@php.net
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


 [2002-10-14 19:26 UTC] php-bugs at lists dot php dot net
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".
 [2002-10-15 09:40 UTC] taylorfdavis at netscape dot net
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
 [2002-10-18 03:29 UTC] ivo at ibuildings dot nl
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?
 [2002-10-22 08:45 UTC] ronnie at rustybrick dot com
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.
 [2002-11-11 03:12 UTC] mderk at yandex dot ru
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.
 [2002-11-12 14:33 UTC] Julian dot Bond at ecademy dot com
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.
 [2002-12-07 20:05 UTC] webmaster at jumpthru dot com
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.
 [2002-12-07 20:32 UTC] webmaster at jumpthru dot com
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
 [2002-12-12 18:25 UTC] brad at kieser dot net
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!
 [2003-01-23 14:28 UTC] mgruenb at gmx dot net
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...
 [2003-01-24 23:12 UTC] oscar at cerecita dot com
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.
 [2003-01-27 08:15 UTC] phpbugs at mx4k dot com
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.
 [2003-01-29 05:25 UTC] cold80 at libero dot it
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...
 [2003-01-29 06:02 UTC] sniper@php.net
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)

 [2003-01-30 03:52 UTC] cold80 at libero dot it
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!
 [2003-02-08 01:01 UTC] sniper@php.net
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.


 [2003-03-21 06:35 UTC] jsarac at fi dot uba dot ar
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
 [2003-04-18 09:01 UTC] php at rjs3 dot com
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?
 [2003-04-21 19:25 UTC] skye at f4 dot ca
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.
 [2003-04-22 09:02 UTC] php at rjs3 dot com
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.
 [2003-05-05 03:09 UTC] e dot aderhold at pro-seco dot de
(/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
 [2003-07-08 02:31 UTC] wieri420 at planet dot nl
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.
 [2003-07-27 20:40 UTC] alexbodn at 012 dot net dot il
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
 [2003-07-27 21:01 UTC] alexbodn at 012 dot net dot il
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
 [2003-07-28 00:01 UTC] leiflists at tanukisoftware dot com
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
 [2004-01-04 12:58 UTC] rajiv at rajivlodha dot cjb dot net
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
 [2004-01-04 13:01 UTC] rajiv at rajivlodha dot cjb dot net
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
 [2004-01-11 20:19 UTC] lennaert dot goris at ellips dot ws
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.
 [2004-01-19 17:01 UTC] oliver at realnet dot org
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.
 [2004-01-19 21:02 UTC] haccel at email dot com
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.
 [2004-01-21 08:45 UTC] august24_70 at yahoo dot com
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
 [2004-03-01 20:15 UTC] stewart dot james at vu dot edu dot au
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
 [2004-03-11 01:05 UTC] haccel at email dot com
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.
 [2004-03-26 16:15 UTC] guertin at brucemaudesign dot com
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.
 [2004-03-26 16:40 UTC] guertin at brucemaudesign dot com
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.
 [2004-04-02 12:01 UTC] phpbugs at chime dot tv dot cutthis
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.
 [2004-04-03 07:10 UTC] nicolas at swarm dot cc
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 :)
 [2004-05-18 07:01 UTC] oliver at veryhip dot com
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 =]
 [2004-07-12 03:02 UTC] oliver at veryhip dot com
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.
 [2007-01-03 21:49 UTC] stranger at teuton dot org
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()
 [2007-12-28 23:45 UTC] allan at emeraldforest dot com
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.
 [2008-01-19 22:07 UTC] ozdemir_e at yahoo dot com
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
 [2008-02-28 12:04 UTC] m1ckx at hotmail dot com
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.
 [2008-02-28 17:50 UTC] rasmus@php.net
session.save_path = "0;\tmp"

??  What is 0;\tmp supposed to mean?
 [2009-03-31 20:15 UTC] prikid at gmail dot com
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
 [2010-07-04 05:14 UTC] glspeed at juno dot com
I do not know if mine is the same "bug"  I went to my site: http://www.videotime.info and I got the following code:
Warning: Unknown: open(/tmp/www.videotime.info/sess_2d42195412bd7242893f1ce67b531875, O_RDWR) failed: Permission denied (13) in Unknown on line 0

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

I was looking for a solution for this and found your website.  Should I reinstall?  Will that remedy it temporarily?

Gino
 [2011-01-04 22:33 UTC] jamontoya at unitec dot edu
I just changed the privileges to directory where session files were expected to be saved, that solved this issue.
 [2015-06-10 08:43 UTC] dutchprogrammer at gmail dot com
I had the same error everything was correct like the setting the folder permissions.

It looks like an bug in php in my case because when i delete my PHPSESSID cookie it was working again so aperently something was messed up and the session got removed but the cookie was still active so php had to define the cause differently and checking first if the session file is still they and give another error and not the permission error
 [2015-06-17 07:10 UTC] roel dot duijnhoven at gmail dot com
A single user of our website keeps getting these errors! They occur after a file upload. I cannot reproduce them myself but do see them popping up in NewRelic.

Enough disk space and most other sessions work just fine.

I am using PHP 5.5.18.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Nov 17 05:01:31 2019 UTC