too-many-files-open issue with 5.2.12

[jrmarino]

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:

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?

 

[jrmarino]

FYI, here is the top stub of the PHP INFO function

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

 

[NiteWave]

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

 

[mistwang]

I think APC have file descriptor leak problem. Should upgrade APC.

 

[jrmarino]

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.

 

[jrmarino]

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.

 

[NiteWave]

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."

 

[jrmarino]

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.

 

[NiteWave]

so the issue should not exist(or not easy to detect) on litespeed + PHP suExec?since lsphp process is not persistent in this case

 

[jrmarino]

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.