|
|

02-13-2010, 01:02 AM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
too-many-files-open issue with 5.2.12
I can't seem to solve this php 5.2.12 problem.
PHP 5.2.12 is built from scratch using litespeed LSAPI 5.3 (but the same thing happens with 5.2 and 4.10), gcc 4.4.3. I am also running APC 3.0.19.
After about 12 hours, I get variations of this message on the server:
Code:
Warning: require_once({MYDIR}/Settings.php) [function.require-once]: failed to open stream:
Too many open files in {MYDIR}/index.php on line 55
Fatal error: require_once() [function.require]:
Failed opening required '{MYDIR}/Settings.php' (include_path='.:') in {MYDIR}/index.php on line 55
When I drop back to php 5.2.8, I don't get the errors. Restarting the lsphp spawn will fix the error, but it returns in about 12 hours.
Is this an issue with LSAPI / Litespeed, or a weird build bug in PHP itself?
|

02-13-2010, 01:05 AM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
FYI, here is the top stub of the PHP INFO function
Code:
slayton-root# ./lsphp5212B -i | more
phpinfo()
PHP Version => 5.2.12
System => SunOS slayton 5.10 Generic_118855-33 i86pc
Build Date => Feb 12 2010 13:12:55
Configure Command => './configure' '--prefix=/opt/csw' '--with-layout=GNU' '--enable-memory-limit' '--enable-libxml' '--with-
libxml-dir=/opt/csw' '--enable-reflection' '--enable-spl' '--program-prefix=' '--disable-cli' '--with-zlib' '--with-litespeed'
'--with-regex=php' '--enable-mbstring' '--enable-ftp' '--disable-filter' '--with-openssl=/opt/csw' '--with-iconv=/opt/csw' '--w
ith-mcrypt=/opt/csw' '--with-freetype-dir=/opt/csw' '--with-jpeg-dir=/opt/csw' '--with-png-dir=/opt/csw' '--with-gd' '--without
-sqlite' '--without-pdo-sqlite' '--with-mysql=/opt/csw/mysql5' '--with-pdo-mysql=/opt/csw/mysql5'
Server API => LiteSpeed V5.3
Virtual Directory Support => disabled
Configuration File (php.ini) Path => /opt/csw/etc
Loaded Configuration File => /opt/csw/etc/php.ini
Scan this dir for additional .ini files => (none)
additional .ini files parsed => (none)
PHP API => 20041225
PHP Extension => 20060613
Zend Extension => 220060519
Debug Build => no
Thread Safety => disabled
Zend Memory Manager => enabled
IPv6 Support => enabled
Registered PHP Streams => https, ftps, compress.zlib, php, file, data, http, ftp
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, sslv2, tls
Registered Stream Filters => zlib.*, convert.iconv.*, string.rot13, string.toupper, string.tolower, string.strip_tags, convert.
*, consumed
|

02-13-2010, 09:50 PM
|
|
LiteSpeed Staff
|
|
Join Date: Sep 2009
Posts: 2,291
|
|
|
googled a while ... no much help. but got a hint at a time: how about try newer APC(say 3.1.3p1) other than current 3.0.19
|

02-18-2010, 10:15 AM
|
|
LiteSpeed Staff
|
|
Join Date: May 2003
Location: New Jersey
Posts: 7,603
|
|
|
I think APC have file descriptor leak problem. Should upgrade APC.
|

02-18-2010, 10:59 AM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
|
The problem with the theory is two-fold:
1) When I drop back down to 5.2.8, I don't change the APC. It's the same accelerator for both versions, yet I only see the file descriptor issue on 5.2.12
2) 3.0.19 is the latest in the stable branch. A known problem would have posted (I would think). 3.1.x is a beta branch.
The simplest test, of course, is to disable APC althogether and see if 5.2.12 crashes after 12 hours. If so, we know APC is not the culprit.
|

08-08-2010, 01:41 AM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
I've finally tracked this file descriptor leakage problem down. It is a bug in PHP that has existed since 5.2.9, as described in this bug report:
http://bugs.php.net/bug.php?id=47675
It specifically affects Solaris 10. Recent versions of opensolaris don't have the same problem. If you use solaris 10, you need to patch the main.c file by adding the word "volatile" as described in the bug report. Since doing this, I don't see any more FD leakage.
Although APC has had file descriptor leaking in the past, there seems to be no problem with the latest stable version, APC 3.0.19. It looks like the latest LSAPI 5.4 is okay too.
|

08-08-2010, 11:09 PM
|
|
LiteSpeed Staff
|
|
Join Date: Sep 2009
Posts: 2,291
|
|
|
Thanks for the update. I'd quote piece of info from above url here:
"PHP was spawned and remains persistent for use with the Litespeed web server (uses the LSAPI interface), so it would run out of file descriptors between 1 and 12 hours on my site."
|

08-09-2010, 05:29 AM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
|
Hi Nitewave,
Actually, I wrote that on the bug report, so I'd be quoting myself. How fast the error comes up depends on the number of pages served and if and when they use the "exit ()" function. The default limit on file descriptors is 256 on Solaris, so it doesn't take too long to hit the limit on an active server.
|

08-09-2010, 07:26 PM
|
|
LiteSpeed Staff
|
|
Join Date: Sep 2009
Posts: 2,291
|
|
|
so the issue should not exist(or not easy to detect) on litespeed + PHP suExec?since lsphp process is not persistent in this case
|

08-09-2010, 10:18 PM
|
|
Senior Member
|
|
Join Date: Apr 2007
Posts: 114
|
|
|
NiteWave,
If that setup means Litespeed launches a new instance of PHP for each page serve and then it terminates, it means you would not detect the issue. Assume the setup was on Solaris 10 and assuming the php script exited early using the exit procedure, PHP would leak one file descriptor and it would shut down itself.
So yes, I believe you would only see it in fastcgi / LSAPI type setups where one instance of PHP resides in memory and serves many pages.
|
| Thread Tools |
|
|
| Display Modes |
Linear Mode
|
Posting Rules
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is Off
|
|
|
All times are GMT -7. The time now is 10:34 PM.
|
|