#19022 [Com]: PHP Warning: Failed to write session data (files)

[alexbodn at 012 dot net dot il]

ID: 19022
Comment by: alexbodn at 012 dot net dot il
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:

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


Previous Comments:
------------------------------------------------------------------------

[2003-07-08 02:31:23] 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-05-05 03:09:15] 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-04-22 09:02:12] 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-04-21 19:25:04] 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-18 09:01:34] 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?

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/19022[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=19022&edit=1[/url]

[alexbodn at 012 dot net dot il]

ID: 19022
Comment by: alexbodn at 012 dot net dot il
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:

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


Previous Comments:
------------------------------------------------------------------------

[2003-07-27 20:40:41] 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-08 02:31:23] 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-05-05 03:09:15] 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-04-22 09:02:12] 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-04-21 19:25:04] 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.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/19022[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=19022&edit=1[/url]

[leiflists at tanukisoftware dot com]

ID: 19022
Comment by: leiflists at tanukisoftware dot com
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:

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


Previous Comments:
------------------------------------------------------------------------

[2003-07-27 21:01:38] 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-27 20:40:41] 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-08 02:31:23] 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-05-05 03:09:15] 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-04-22 09:02:12] 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.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/19022[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=19022&edit=1[/url]

[stranger at teuton dot org]

ID: 19022
Comment by: stranger at teuton dot org
Reported By: phpbugs at mx4k dot com
Status: No Feedback
Bug Type: Session related
Operating System: linux (rh7.3), apache 1.3.26
PHP Version: 4.2.2
New Comment:

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()


Previous Comments:
------------------------------------------------------------------------

[2004-07-12 03:02:26] 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.

------------------------------------------------------------------------

[2004-05-18 07:01:46] 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-04-03 07:10:23] 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-04-02 12:01:59] 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: [url]http://chir.ag/test.php[/url]
Server B: [url]https://secure.magictanorders.com/test.php[/url]

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-03-26 16:40:43] 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.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
[url]http://bugs.php.net/19022[/url]

--
Edit this bug report at [url]http://bugs.php.net/?id=19022&edit=1[/url]