too-many-files-open issue with 5.2.12

Discussion in 'PHP' started by jrmarino, Feb 13, 2010.

  1. jrmarino

    jrmarino Well-Known Member

    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?
  2. jrmarino

    jrmarino Well-Known Member

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

    slayton-root# ./lsphp5212B -i | more
    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
  3. NiteWave

    NiteWave Administrator

    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
  4. mistwang

    mistwang LiteSpeed Staff

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

    jrmarino Well-Known Member

    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.
  6. jrmarino

    jrmarino Well-Known Member

    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:

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

    NiteWave Administrator

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

    jrmarino Well-Known Member

    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.
  9. NiteWave

    NiteWave Administrator

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

    jrmarino Well-Known Member

    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.

Share This Page