#43579 [Com]: sessions time out on 5.2.5
ID: 43579
Comment by: jsnyxx at gmail dot com
Reported By: assid at assid dot com
Status: Open
Bug Type: Session related
Operating System: Debian etch
PHP Version: 5.2.5
New Comment:
sv4php - have you tried reverting the patch made in the
ext/session/mod_files.c?
Just an idea but this bug (#42596 (session.save_path MODE option does
not work)) was fixed in between the PHP 5.2.4 and 5.2.5 releases.
Link is here for patch diff:
http://cvs.php.net/viewvc.cgi/php-src/ext/session/mod_files.c?r1=1.100.2.3.2.9&r2=1.100.2.3.2.10&pathrev=PHP_5_2
Previous Comments:
[2008-03-01 21:56:15] sv4php at fmethod dot com
I had the chance to test this issue with Assid on his server and we
were able to more accurately pin point the issue:
1) the sessions don't time out, instead we're talking about
session_name() selectively being ignored (which results in two session
cookies, and hence sessions, created)
2) the issue seems to only happen on PHP 5.2.5 without --enable-debug.
On 5.2.4 it doesn't happen, on 5.2.5 with --enable-debug we couldn't
repro, but this needs more testing.
3) the issue may be hardware/configuration dependent (32-64 bit? OS
distro? I don't have those details, Assid could provide them). The
Apache server on the tested configuration runs in prefork mode, so it
can't be a threading race condition (as far as I know).
4) we reverted the patch for bug http://bugs.php.net/42596 and
recompiled 5.2.5 but still were able to reproduce the issue. Since this
is the only change in the session module between 5.2.4 and 5.2.5, I have
to conclude the issue is related to some other code (somehow..).
Description of the reproduce steps.
We have userA and userB on different machines, IP-s. They both are
given the url to the example with the counter as Assid provided it.
Notice the example uses session_name('spheretest').
If a userA refreshes the page alone, he gains session cookie
'spheretest' and the counter works normally.
If userB refreshed the page, userA gains a new cookie 'PHPSESSID' and a
new session. After userA refreshes few more times, PHP gets back to
using the previous 'spheretest' session/cookie.
We tested if the issue is related to prematurely starting session
*before* the session_name() call. But no, session_id is never defined
before the session_name() call.
[2008-03-01 02:36:28] assid at assid dot com
err sorry, session counter reset to 1 on refresh on the previous post.
[2008-03-01 02:34:58] assid at assid dot com
Okay, finally found out how to do valgrind with apache :P
During valgrind, phpmyadmin was behaving properly, squirrelmail as i
mentioned in my previous post is erratic, but it normally takes time to
crash, once it does, then it happens more frequently.
I later tried the session script as spherelinx.com/session.php (check
phps)
This counter was working fine here again.
I then decided to visit alternate sites on the server perhaps to create
more session files.
I visited www.equineindia.com, and then i started hitting on
session.php again, voila! session counter was reset to 0
I tried to see if i could simulate more of the sessions disappearing
etc, like it going back to the original counter, but it didnt go,
(normally you keep hitting refresh, you just might get back). I guess i
should have tried more, but the day was just beginning and had to let
the public in once again. So i decided, we atleast got the basics of
what was causing this, and atleast report this.
The valgrind log is available at: http://assid.com/apache1.log
Btw: yes apc , and fileinfo from pecl were disabled before I did this.
the main page of equineindia refreshes to login.php ; please visit
login.phps for the source of the same.
Interestingly, the leak summary shows alot of leakage BTW.
[2008-02-28 18:13:40] assid at assid dot com
this will be difficult, we provide shared hosting on this box, and will
be difficult to just shut it down for that period of time. but lets see
what i can do.
Can you tell me how exactly do i put the whole apache process through
valgrind ?
[2008-02-28 17:52:40] [EMAIL PROTECTED]
The libdl stuff can be ignored, so that looks like a clean valgrind
run. But, are you sure the problem happens on the command line? I'd
run the entire apache -X through valgrind. You'd need to do it on a
quiet machine somewhere that isn't getting hit, of course, so you can
control the requests you send to it while valgrind is run
#43579 [Com]: sessions time out on 5.2.5
ID: 43579 Comment by: jsnyxx at gmail dot com Reported By: assid at assid dot com Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: Hi Rasmus Yes, we can confirm that nothing changed on the box apart from php 5.2.4 -> 5.2.5. We found it easier to reproduce the bug once XCache was installed, but the bug still exists even when we remove Xcache, it's just more intermitment. The developer of Xcache thinks this is related to a heap corruption of some sort. See here: http://forum.lighttpd.net/topic/42805 The issue for us seems to be that even though the session file exists on the server (under a private /sessions directory), at some point when the browser sends the cookie with the PHPSESSID header, the server seems to temporarily "lose" the information stored in the session file and returns a blank _$SESSION variable. However, after a few more refreshes it provides the correct info from the $_SESSION variable again. Previous Comments: [2008-02-26 09:32:06] assid at assid dot com Yes, same machine, same everything. Even phpmyadmin dies on me. I just had to move it back. I can apachectl stop; make install; apachectl start ; whenever your online. Since its a production box, i need functionality to work fine, so i moved it back down to 5.2.4 As I said i am available on freenode as Assid [2008-02-26 09:11:13] [EMAIL PROTECTED] There is only a single trivial change to the session extension between 5.2.4 and 5.2.5 and it was to fix http://bugs.php.net/42596 The change is here: http://cvs.php.net/viewvc.cgi/php-src/ext/session/mod_files.c?r1=1.100.2.3.2.9&r2=1.100.2.3.2.10&pathrev=PHP_5_2&diff_format=u I don't see how this change could have caused these problems. Could you please verify that 5.2.4 works under the exact same conditions that 5.2.5 doesn't work? That is, on the same machine, built the same way and running the same code. [2008-02-26 08:27:56] assid at assid dot com Hrm, strange, i dont use xcache. But yeah session integrity is messed up. Looks like we gotta wait for 5.2.6 and hope the developers fixed that bug. It does seem php5.2-200802241730 is still not done, as a matter of fact, the session file in -dev seems to disappear, whereas atleast in 5.2.5 it remains. (very little testing in -dev btw). So its gone from bad to worse. - Data integrity ? - Another important note, is that phpmyadmin acts super strange as well. The css i believe is generated on the fly, that goes awry and sql queries start yielding no results. I am not sure if this is session related. or not! -------- [2008-02-26 08:02:18] jsnyxx at gmail dot com Rasmus -- verified that this issue (PHP session being randomly lost) is also occurring for us on php 5.2.5 but not php 5.2.4 on our Linux Centos 4.4 box. Please also see here for our own reproduce code: http://xcache.lighttpd.net/ticket/163 [2008-02-25 14:23:44] assid at assid dot com I have to downgrade to 5.2.4, as this is a production box. Please let me know when you are available, and I will load the necessary module at that moment. I am also available on IRC / freenode as Assid 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/43579 -- Edit this bug report at http://bugs.php.net/?id=43579&edit=1
#43579 [Com]: sessions time out on 5.2.5
ID: 43579 Comment by: jsnyxx at gmail dot com Reported By: assid at assid dot com Status: Open Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: Rasmus -- verified that this issue (PHP session being randomly lost) is also occurring for us on php 5.2.5 but not php 5.2.4 on our Linux Centos 4.4 box. Please also see here for our own reproduce code: http://xcache.lighttpd.net/ticket/163 Previous Comments: [2008-02-25 14:23:44] assid at assid dot com I have to downgrade to 5.2.4, as this is a production box. Please let me know when you are available, and I will load the necessary module at that moment. I am also available on IRC / freenode as Assid [2008-02-25 13:12:46] assid at assid dot com With regards to session files and squirrelmail I checked the part that you told me. The headers look exactly the same. Sometimes I get the session kicking me out. The headers during which, looks exactly the same as the ones when it doesnt kick me out. However, sometimes i just rightclick in that frame and reload frame and it works, or i click on any of the available imap folders on the left side. During the time it kicks me out, the session file still exists, would explain WHY i can still continue using AFTER that. from my previous test and this into consideration, i would GUESS its something to do with session generation / session file handling or something related to this. [2008-02-25 08:30:07] assid at assid dot com okay here you go, 5 hours of sleep helped a bit. http://spherelinx.com/session.php Now refresh this slowly (i mean one F5 per second or 2 seconds), till you hit something like 8-10. Now press F5 rapidly (dont hold), like 5-8 times. You end up with a new counter. Refresh this counter slowly, and again repeat the above step. Sometimes you get it to go back to the older counter. reproduce code: http://spherelinx.com/session.phps phpinfo - http://spherelinx.com/phpinfo.php >From my guess, session_name fails or causes some kind of glitch [2008-02-25 01:28:12] [EMAIL PROTECTED] Many people, including myself, are running SquirrelMail quite fine on 5.2.5 without any sort of session problems. The fact that it also happens in other applications points to a general problem on your end. Sessions are really simple. There are 3 parts to an active session. 1. Your browser sends a session cookie 2. The PHP script that receives the cookie calls session_start() 3. session_start() reads the session data from the session data So, to debug this, look at each part. Install something like the LiveHTTPHeaders Firefox extension and make sure the cookie is being sent. Second, make sure there is a session_start() call in the receiving code. And third, check to make sure that the session data is in the session data store. If you are using the file-based session store, match the session cookie to the session filename and watch it as you click around. Does it suddenly disappear? If so, figure out why. Also check all your session.* settings and if you have multiple servers behind any sort of load balancer, a per-server file-based session store obviously won't work. NFS-based stuff can also cause problems for a file-based session store. You can also write your own very simple trivial session test to verify that sessions are working at all on your setup. [2008-02-24 20:23:25] assid at assid dot com The problem is I didnt make squirrelmail. So i am not sure of what i can provide as the reproducable script. I am using the current stable release. I wanted to give something else to my users in the meantime, so i tried horde, and well, that seems to have session timeout issues as well. 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/43579 -- Edit this bug report at http://bugs.php.net/?id=43579&edit=1
#43579 [Com]: sessions time out on 5.2.5
ID: 43579 Comment by: jsnyxx at gmail dot com Reported By: assid at assid dot com Status: No Feedback Bug Type: Session related Operating System: Debian etch PHP Version: 5.2.5 New Comment: We've found similar problems -- see our report here: http://xcache.lighttpd.net/ticket/163 (We initially thought that it was Xcache, but that doesn't seem to be the case now). Previous Comments: [2008-02-05 08:04:13] poil at quake dot fr I got the same issue; I have a variable $_SESSION['S_num_content'] who got reseted randomly. I have a small navigation div who is refresh by ajax. I increment or decrement the value of $_SESSION['S_num_content'] for limiting my SQL request to "x, x+10". This browsing work correctly. When choosing link in this menu for displaying the news (not ajax, full webpage refresh), sometime session is lost value (1 clic of 5). If I navigate very slowly, the session is less lost (1 clic of 10 or 20) My english isn't very good for explain it; I go to try to create a small parts of code who do the same things. You can see it on http://www.teewars.net Clic on "<< Précédent" one time, Select an article in the same menu sometime the list of menu stay where it should be sometime not. Before changing to php 5.2.5 I don't have this issue. I was in php 4.x before my webhoster upgrade my hosting. Best regards [2007-12-21 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, 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". [2007-12-13 09:19:31] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2007-12-12 11:01:14] assid at assid dot com btw: thats not the reproduce code, its the phpinfo just incase needed [2007-12-12 10:53:02] assid at assid dot com Description: I tried upgrading to php 5.2.5 from 5.2.4 and ever since i did that my sessions have been acting strange. It seems most noticable using squirrelmail. Downgrading back to 5.2.4 seems to have fixed this issue, so its definitely something on how 5.2.5 handles sessions Reproduce code: --- http://spherelinx.com/phpinfo.php http://assid.pastebin.com/f7ba83639 <-- yes i know certain configure options have been deprecated. but using the same config.nice for both Expected result: session management similar to 5.2.4 where it doesnt just timeout for no apparent reason. -- Edit this bug report at http://bugs.php.net/?id=43579&edit=1
