12

I am running Mac OS X 10.9.4, including the builtin apache2 webserver with PHP 5.5.14 from brew (packages: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

When running this setup it works quite well. However, after some time, I will run on 403 errors for every request. I have looked up the apache error log, and found something like the following:

[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Warning:  require_once(/Users/daniel/Development/massiveart/sulu-complete/app/bootstrap.php.cache): failed to open stream: Too many open files in /Users/daniel/Development/massiveart/sulu-complete/web/website.php on line 10, referer: http://sulu.lo/de
[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Stack trace:, referer: http://sulu.lo/de
[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP   1. {main}() /Users/daniel/Development/massiveart/sulu-complete/web/website.php:0, referer: http://sulu.lo/de
[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Fatal error:  require_once(): Failed opening required '/Users/daniel/Development/massiveart/sulu-complete/web/../app/bootstrap.php.cache' (include_path='.:/usr/local/Cellar/php55/5.5.14/lib/php') in /Users/daniel/Development/massiveart/sulu-complete/web/website.php on line 10, referer: http://sulu.lo/de
[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Stack trace:, referer: http://sulu.lo/de
[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP   1. {main}() /Users/daniel/Development/massiveart/sulu-complete/web/website.php:0, referer: http://sulu.lo/de
[Fri Jul 25 05:28:40 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de
[Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de
[Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de
[Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de
[Fri Jul 25 05:28:45 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de
[Fri Jul 25 05:28:45 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de

It looks to me like the file cannot be read anymore, and it returns the 403 somehow. I already found out about certain limits, but launchctl returns I have an unlimited hard limit on open files:

 ~ $ launchctl limit
    cpu         unlimited      unlimited
    filesize    unlimited      unlimited
    data        unlimited      unlimited
    stack       8388608        67104768
    core        0              unlimited
    rss         unlimited      unlimited
    memlock     unlimited      unlimited
    maxproc     709            1064
    maxfiles    256            unlimited

I have also already tried to set the maxfiles to 4096 with the command launchctl limit maxfiles 4096 16384, but the issue still returns after some time. Any idea what else I can check?

UPDATE: When running the lsof -c httpd command as suggested by Gordon Davisson, I can see that there are loads of entries like the following:

httpd   1361 _www   15u    IPv4 0xb306b48659f63853       0t0     TCP localhost:50603->localhost:cslistener (CLOSED)

I can say that the application I use is using websockets, and is also using a fallback when websockets are not available or the counterpart is not running on the server. What confuses me is the (CLOSED)-part, why is it still listed?

UPDATE: After some time I looked up the cslistener port, which actually is 9000, which again is which port xdebug is listening for remote debugging. So I guess I have got some wrong configuration there, or it is a bug in xdebug (I am using XDebug 2.2.5, installed by brew)

14

Are you using PHPStorm with XDEBUG on Mac?

I have the same problem. I found an open bug filed with XDEBUG here:

http://bugs.xdebug.org/view.php?id=1070

Update

This bug has now been fixed:

I just merged a patch by Sean Dubois, which should fix this \o/! The patch is going to be in 2.3.4 and 2.4.0.

I believe this is the commit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Make sure you are using an updated version with this patch.

  • Not really a solution, but I think it answers the question – Daniel Rotter Nov 6 '14 at 9:44
  • Basically, Xdebug is leaking file descriptors for connection listeners (sorry if this is technically incorrect, that's the idea) when the debugging client is not open. To solve the problem, make sure the debugger client is open when the remote debugger starts a debugging session. Of course, a better solution would be a fix to the bug by the developers. – mcdado Nov 14 '14 at 10:49
  • This also happens with some debuggers open (for instance PhpStorm). Hopefully they'll fix it :) – Steve Tauber Nov 18 '14 at 9:56
  • This is pretty major, I hope a fix will be issued soon. – Hubert Perron Nov 20 '14 at 15:33
  • 1
    Another workaround is to set xdebug.remote_enable=0 in php.ini to turn of xdebug remote connections when not using them. Apache restart required. – Gregory Cosmo Haun Feb 2 '16 at 23:05
7

I'm pretty sure you have something running in apache (probably the PHP module, but it's hard to be sure) that's leaking file descriptors. That is, it's opening files and then just leaving them open indefinitely. If this is the case, increasing the open file limit just makes it take longer to hit the limit. What you really need to do is track down what's opening all the files and leaving them open.

You can probably get some idea what's going on with the lsof("LiSt Open Files") command:

sudo lsof -c httpd

Run it when apache hasn't been running for long to see what's normal, then again when it hits the limit. Look in the second output for lots of additional files that aren't there in the first listing. Note that this will be complicated somewhat by the fact that it'll list the files opened by all httpd processes, and (depending on your apache settings and server load) there may be a large number of them; the important thing is the number of files opened by a single process, not the total across all server processes. You can also use sudo lsof -p someprocessID to list just a single server process at a time.

Hopefully seeing what the extra open files are will give you a good idea what's opening them and leaving them open.

  • Tried it, I haved updated the question. – Daniel Rotter Jul 28 '14 at 5:43
  • I'm not very familiar with the exact meaning of the TCP socket states, but it sounds to me like the connections to the counterpart aren't getting closed properly. Is that running on the cslistener port (number 9000)? How exactly does your app close the connections to its counterpart? Is it possible it's closing the TCP session, but not the file descriptor? – Gordon Davisson Jul 28 '14 at 6:18
  • 1
    I found out that 9000 is the port xdebug is listening on, so is it possible that the error is in this extension? – Daniel Rotter Jul 28 '14 at 8:46
3

Adding following line to xdebug.ini also solved the problem for me

xdebug.remote_autostart = 0
1

I'm getting the same thing with OSX 10.9.4 and both Apache 2.2 and PHP 5.3 from Brew.

While this doesn't actually fix the problem, you can contain it by setting the Apache MaxRequestsPerChild setting to something like 10 - which should be fine for development.

diff -r 2c0473b696fd -r acf809f04b17 apache2/2.2/httpd.conf
--- a/apache2/2.2/httpd.conf    Thu Aug 14 16:14:25 2014 -0500
+++ b/apache2/2.2/httpd.conf    Thu Aug 14 16:19:10 2014 -0500
@@ -437,7 +437,7 @@
 # necessary.

 # Server-pool management (MPM specific)
-#Include /usr/local/etc/apache2/2.2/extra/httpd-mpm.conf
+Include /usr/local/etc/apache2/2.2/extra/httpd-mpm.conf

 # Multi-language error messages
 #Include /usr/local/etc/apache2/2.2/extra/httpd-multilang-errordoc.conf
diff -r 2c0473b696fd -r acf809f04b17 apache2/2.2/extra/httpd-mpm.conf
--- a/apache2/2.2/extra/httpd-mpm.conf  Thu Aug 14 16:14:25 2014 -0500
+++ b/apache2/2.2/extra/httpd-mpm.conf  Thu Aug 14 16:19:10 2014 -0500
@@ -38,7 +38,7 @@
     MinSpareServers       5
     MaxSpareServers      10
     MaxClients          150
-    MaxRequestsPerChild   0
+    MaxRequestsPerChild  10
 </IfModule>

 # worker MPM

That should save you at least from having to restart apache every so often to get rid of those leaked files

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.