Edit report at https://bugs.php.net/bug.php?id=47640&edit=1
ID: 47640 Updated by: yohg...@php.net Reported by: manuel dot schmitt at manitu dot de Summary: Session does not unlock file in /tmp/ -Status: Open +Status: Feedback Type: Bug Package: Session related Operating System: Linux PHP Version: 5.2.9 Block user comment: N Private report: N New Comment: Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ I really don't have clue why you had such problem with 5.2.9. May be suexec thing. Please try 5.5 or 5.4. Previous Comments: ------------------------------------------------------------------------ [2012-09-12 17:56:16] connie at jaygoss dot com I just encountered this bug on version 5.3.13. The script worked fine for about a year, then stopped working for no known reason (no code changes, version upgrades, etc.) This script works: echo "<br>Flock Test Without Session<br>"; $fp = fopen("_order_id.txt", "r+"); if (flock($fp, LOCK_EX)) { /* do an exclusive lock to get an order number */ $id = fread($fp,filesize("_order_id.txt")); $id++; echo "<br>Got the lock, id is now $id"; ftruncate($fp, 0); /* truncate file */ rewind($fp); /* reset pointer */ fwrite($fp, $id); /* write new order id */ flock($fp, LOCK_UN); /* release the lock */ } else { echo "Couldn't get the lock"; } However, if I put the same code inside a session, it fails on my live site, but still works fine in my localhost (version 5.3.8): session_start(); echo "<br>Flock Test With Session<br>"; $fp = fopen("_order_id.txt", "r+"); if (flock($fp, LOCK_EX)) { /* do an exclusive lock to get an order number */ $id = fread($fp,filesize("_order_id.txt")); $id++; echo "<br>Got the lock, id is now $id"; ftruncate($fp, 0); /* truncate file */ rewind($fp); /* reset pointer */ fwrite($fp, $id); /* write new order id */ flock($fp, LOCK_UN); /* release the lock */ } else { echo "Couldn't get the lock"; } session_destroy(); ------------------------------------------------------------------------ [2012-09-12 03:14:57] ahar...@php.net Explanation provided separately, since it's not relevant to this bug. Bug reopened. ------------------------------------------------------------------------ [2012-09-12 03:10:26] larue...@php.net ...maybe it's chagned by the reporter self, no action history log in the changes tab ------------------------------------------------------------------------ [2012-09-11 20:39:24] kriscr...@php.net Could somebody explain why the status was changed to "Not a bug?" I'm not seeing anything in the comments to indicate why that edit was made. Looks like a real bug to me and everything else seems to check-out, so I'm assuming that was an error given the lack of an explanation. I'm re-opening this with "Feedback" status. If you're the one who closed this (the edit history is empty), please post a comment explaining your reasoning. Thanks! ------------------------------------------------------------------------ [2012-05-27 01:04:29] bugs dot php dot net at jrs-s dot net I worked around this problem by simply moving sessions from file storage to memcache. session.save_handler = memcache session.save_path = "tcp://serv01:11211,tcp://serv02:11211,tcp://serv03:11211" An application pool that had been creeping up to MaxCli (900 children apiece, in this case) within a couple hours of a restart due to this FLOCK issue settled down and has now been running happily for several days on fewer than 150 children per server. I highly recommend just NOT USING php's file based session storage in the first place, because of exactly 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 https://bugs.php.net/bug.php?id=47640 -- Edit this bug report at https://bugs.php.net/bug.php?id=47640&edit=1
