“Muitos arquivos abertos” no Mac OSX depois de executar o apache em PHP com o XDebug por algum tempo

Question

Estou executando o Mac OS X 10.9.4, incluindo o servidor web apache2 integrado com o PHP 5.5.14 a partir do brew (pacotes: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

Ao executar esta configuração, ela funciona muito bem. No entanto, depois de algum tempo, irei rodar em 403 erros para cada requisição. Eu procurei o log de erros do apache e encontrei algo como o seguinte:

[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

Parece-me que o arquivo não pode mais ser lido e retorna o 403 de alguma forma. Eu já descobri sobre certos limites, mas retorna launchctl Eu tenho um limite ilimitado em arquivos abertos:

 ~ $ 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

Eu também já tentei definir os maxfiles para 4096 com o comando launchctl limit maxfiles 4096 16384 , mas o problema ainda retorna depois de algum tempo. Alguma ideia do que mais posso verificar?

UPDATE : Ao executar o comando lsof -c httpd , como sugerido por Gordon Davisson, posso ver que há muitas entradas como as seguintes:

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

Posso dizer que o aplicativo que utilizo está usando websockets e também está usando um fallback quando os websockets não estão disponíveis ou a contraparte não está em execução no servidor. O que me confunde é o (CLOSED) -part, por que ele ainda está listado?

UPDATE : Depois de algum tempo eu olhei para a porta cslistener, que na verdade é 9000, que novamente é qual porta xdebug está escutando depuração remota. Então eu acho que tenho alguma configuração errada lá, ou é um bug no xdebug (estou usando o XDebug 2.2.5, instalado pelo brew)

    

Answer 1

Você está usando o PHPStorm com o XDEBUG no Mac?

Eu tenho o mesmo problema. Eu encontrei um bug aberto arquivado com o XDEBUG aqui:

link

Atualizar

Este bug foi corrigido:

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.

Acredito que este seja o commit: link

Verifique se você está usando uma versão atualizada com este patch.

    

Answer 2

Tenho certeza que você tem algo em execução no apache (provavelmente o módulo PHP, mas é difícil ter certeza) que está vazando descritores de arquivo. Ou seja, ele está abrindo arquivos e depois deixando-os abertos indefinidamente. Se esse for o caso, aumentar o limite de arquivos abertos fará com que demore mais para atingir o limite. O que você realmente precisa fazer é rastrear o que está abrindo todos os arquivos e deixando-os abertos.

Você provavelmente pode ter uma ideia do que está acontecendo com o comando lsof ("LiSt Open Files"):

sudo lsof -c httpd

Execute-o quando o apache não estiver em execução por muito tempo para ver o que é normal e, novamente, quando atingir o limite. Olhe na segunda saída para muitos arquivos adicionais que não estão lá na primeira listagem. Observe que isso será um pouco complicado pelo fato de listar os arquivos abertos pelos processos all httpd e (dependendo das configurações do apache e da carga do servidor) pode haver um grande número deles; O importante é o número de arquivos abertos por um único processo, não o total de todos os processos do servidor. Você também pode usar sudo lsof -p someprocessID para listar apenas um único processo de servidor de cada vez.

Espero que, vendo os arquivos abertos, você tenha uma boa ideia do que está abrindo e deixando abertos.

    

Answer 3

Adicionando a seguinte linha ao xdebug.ini também resolveu o problema para mim

xdebug.remote_autostart = 0

    

Answer 4

Estou obtendo a mesma coisa com o OSX 10.9.4 e com o Apache 2.2 e o PHP 5.3 do Brew.

Embora isso não conserte o problema, você pode defini-lo definindo a configuração do Apache MaxRequestsPerChild como algo como 10 - o que deve ser adequado para o desenvolvimento.

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

Isso deve poupar você pelo menos de ter que reiniciar o apache de vez em quando para se livrar desses arquivos que vazaram