#19022 [Com]: PHP Warning: Failed to write session data (files)
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
http://bugs.php.net/19022
--
Edit this bug report at http://bugs.php.net/?id=19022&edit=1
#19022 [Com]: PHP Warning: Failed to write session data (files)
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
http://bugs.php.net/19022
--
Edit this bug report at http://bugs.php.net/?id=19022&edit=1
