“Muitos arquivos abertos” no Mac OSX após executar o apache no PHP com o XDebug por algum tempo

13

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

Ao executar esta configuração, ele funciona muito bem. No entanto, depois de algum tempo, executarei 403 erros para cada solicitaçã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 alguns limites, mas o launchctl retorna um limite ilimitado de 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 o maxfiles para 4096 com o comando launchctl limit maxfiles 4096 16384, mas o problema ainda retorna depois de algum tempo. Alguma idéia do que mais posso verificar?

ATUALIZAÇÃO : Ao executar o lsof -c httpdcomando conforme 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 eu uso está usando websockets e também está usando um fallback quando websockets não estão disponíveis ou a contraparte não está sendo executada no servidor. O que me confunde é a (CLOSED)parte, por que ainda está listada?

ATUALIZAÇÃO : Depois de algum tempo, procurei a porta cslistener, que na verdade é 9000, e novamente qual porta xdebug está ouvindo a 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)

macos apache-http-server php xdebug Daniel Rotter
fonte

Respostas:

14

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

Eu tenho o mesmo problema. Encontrei um bug aberto arquivado no XDEBUG aqui:

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

Atualizar

Este bug foi corrigido:

Acabei de mesclar um patch de Sean Dubois, que deve corrigir esse \ o /! O patch estará nas versões 2.3.4 e 2.4.0.

Acredito que este seja o commit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

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

Steve Tauber
fonte
Não é realmente uma solução, mas eu acho que responde à pergunta
Daniel Rotter
Basicamente, o Xdebug está vazando descritores de arquivo para ouvintes de conexão (desculpe se isso é tecnicamente incorreto, essa é a ideia) quando o cliente de depuração não está aberto. Para resolver o problema, verifique se o cliente do depurador está aberto quando o depurador remoto inicia uma sessão de depuração. Obviamente, uma solução melhor seria uma correção para o bug dos desenvolvedores.
Mcdado
Isso também acontece com alguns depuradores abertos (por exemplo, PhpStorm). Esperemos que eles vão corrigi-lo :)
Steve Tauber
Isso é muito importante, espero que uma correção seja emitida em breve.
precisa
1
Outra solução é definir xdebug.remote_enable=0em php.initransformar de conexões remotas XDebug quando não estiver usando-los. É necessário reiniciar o Apache.
Gregory Cosmo Haun 02/02
7

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, é abrir arquivos e depois deixá-los abertos indefinidamente. Se for esse o caso, aumentar o limite de arquivo aberto apenas leva mais tempo para atingir o limite. O que você realmente precisa fazer é rastrear o que está abrindo todos os arquivos e deixá-los abertos.

Você provavelmente pode ter uma idéia do que está acontecendo com o lsofcomando ("LiSt Open Files"):

sudo lsof -c httpd

Execute-o quando o apache não estiver em execução há muito tempo para ver o que é normal e, novamente, quando atingir o limite. Procure na segunda saída muitos arquivos adicionais que não estão na primeira listagem. Observe que isso será um pouco complicado pelo fato de listar os arquivos abertos por todos os processos 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 em todos os processos do servidor. Você também pode usar sudo lsof -p someprocessIDpara listar apenas um processo de servidor por vez.

Esperamos que ver quais são os arquivos abertos extras lhe dará uma boa idéia do que os está abrindo e deixando em aberto.

Gordon Davisson
fonte
Tentei, eu atualizei a pergunta.
precisa
Não estou muito familiarizado com o significado exato dos estados do soquete TCP, mas parece-me que as conexões com a contraparte não estão sendo fechadas corretamente. Isso está sendo executado na porta do cslistener (número 9000)? Como exatamente seu aplicativo fecha as conexões com o seu homólogo? É possível que esteja fechando a sessão TCP, mas não o descritor de arquivo?
Gordon Davisson
1
Eu descobri que 9000 é a porta que o xdebug está ouvindo, então é possível que o erro esteja nessa extensão?
precisa
3

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

xdebug.remote_autostart = 0
Femi Veys
fonte
1

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

Embora isso não resolva o problema, você pode contê-lo definindo a configuração do Apache MaxRequestsPerChild para algo como 10 - o que deve ser bom 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 evitar que você tenha que reiniciar o apache de vez em quando para se livrar desses arquivos vazados

barryp
fonte