Edit report at https://bugs.php.net/bug.php?id=47640&edit=1
ID: 47640
Comment by: bugs dot php dot net at jrs-s dot net
Reported by: manuel dot schmitt at manitu dot de
Summary: Session does not close file in /tmp/
Status: Not a bug
Type: Bug
Package: Session related
Operating System: Linux
PHP Version: 5.2.9
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2012-02-01 19:50:15] pio at rdl dot pl
Hello !
Is there any news with this issue ?
Piotr
------------------------------------------------------------------------
[2010-10-24 12:29:55] alex dot linte at gmail dot com
Hello,
I have the same mistake :
host:~# date
dimanche 24 octobre 2010, 12:10:03 (UTC+0200)
host:~# ps faux | grep php
juritrav 17749 0.0 0.0 118988 11616 ? S 00:11 0:00 | \_
/usr/bin/php-cgi
suphpuser 17818 0.0 0.0 117764 9536 ? S 00:12 0:00 | \_
/usr/bin/php-cgi
suphpuser 18004 0.0 0.0 117764 9536 ? S 00:14 0:00 | \_
/usr/bin/php-cgi
suphpuser 12573 0.0 0.1 138812 31784 ? S 09:39 0:00 | \_
/usr/bin/php-cgi
suphpuser 12574 0.0 0.0 117492 9396 ? S 09:39 0:00 | \_
/usr/bin/php-cgi
duphpuser 12594 0.0 0.0 117492 9396 ? S 09:39 0:00 | \_
/usr/bin/php-cgi
suphpuser 12675 0.0 0.0 117764 9536 ? S 09:40 0:00 | \_
/usr/bin/php-cgi
suphpuser 12682 0.0 0.0 117764 9536 ? S 09:40 0:00 | \_
/usr/bin/php-cgi
suphpuser 12695 0.0 0.0 117764 9536 ? S 09:40 0:00 | \_
/usr/bin/php-cgi
So php-cgi scripts run for ever until I kill its manually.
I take the sample of process 18004 :
front2:~# strace -p18004
Process 18004 attached - interrupt to quit
flock(3, LOCK_EX
host# lsof -p18004
....
php-cgi 18004 suphpuser 3uW REG 9,1 7 897723
/tmp/php5/sess_xxxxxxxxxxxxxxxxxxxxxxxx (deleted)
....
So the php script tries to lock a session file (file descriptor 3) that has
been deleted by the PHP garbage collector.
When the garbage collector delete a session file, it doesn't take care that any
php process still using this session file.
Then the php process can't lock the file because it doesn't exist anymore, the
php-cgi process is blocked....
I have the problem with the following version of php :
PHP 5.2.6-1+lenny9 with Suhosin-Patch 0.9.6.2 (cli) (built: Aug 4 2010
06:06:53)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies
The cron job for php (script that delete session on debian) is disabled et the
garbage collector php is enabled in php.ini file :
session.gc_probability = 1
session.gc_divisor = 100
Sorry for my english.
Alexandre LINTE
------------------------------------------------------------------------
[2009-05-03 12:07:47] manuel dot schmitt at manitu dot de
ACK, but as server administrator there *must* be a way to prevent this.
Admins do not have influence on the scripts that are used by webmasters.
So I think it's a PHP thing. Likely one should automatically close all sessions
that were opened by scripts aborting / running into limits sets by php (e.g.
exec time) etc. This should solve it.
------------------------------------------------------------------------
[2009-05-02 18:42:02] [email protected]
Endless loops tend to cause such problems. One should always use
http://www.php.net/session_write_close as early as possible to prevent
race conditions and this kind of "bugs".
------------------------------------------------------------------------
[2009-03-17 06:32:36] manuel dot schmitt at manitu dot de
ARGH!
It is so simple!
<?php
session_start();
while (true) { $i *= 2; }
?>
Execute it for the first time and ensure, that it runs into any of the php
limits, e.g. maxmimum execution time.
Call the script a second time while not running into the limit. When tracing
the PHP process you will see an unlimited flock() syscall!
------------------------------------------------------------------------
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
