Estou executando o Mac OS X 10.9.4, incluindo o servidor web apache2 integrado com PHP 5.5.14 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, executarei erros 403 para cada solicitação. Pesquisei 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 403 de alguma forma. Já descobri alguns limites, mas o launchctl retorna que tenho um limite rígido ilimitado para 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
Também já tentei definir 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?
ATUALIZAR: Ao executar o lsof -c httpdcomando 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á rodando no servidor. O que me confunde é a (CLOSED)parte, por que ainda está listada?
ATUALIZAR: Depois de algum tempo, procurei a porta cslistener, que na verdade é 9000, que novamente é a porta que o xdebug está escutando para depuração remota. Então acho que tenho alguma configuração errada ou é um bug no xdebug (estou usando o XDebug 2.2.5, instalado pelo brew)
Responder1
Você está usando PHPStorm com 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 já foi corrigido:
Acabei de mesclar um patch de Sean Dubois, que deve corrigir isso \o/! O patch estará em 2.3.4 e 2.4.0.
Eu acredito que este é o commit:https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9
Certifique-se de que você estáusando uma versão atualizadacom este patch.
Responder2
Tenho certeza que você tem algo rodando no Apache (provavelmente o módulo PHP, mas é difícil ter certeza) que está vazando descritores de arquivos. Ou seja, é abrir arquivos e depois é só deixá-los abertos por tempo indeterminado. Se for esse o caso, aumentar o limite de arquivos abertos apenas 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 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 está 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 portodosprocessos 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 someprocessIDpara listar apenas um processo de servidor por vez.
Esperamos que ver quais são os arquivos extras abertos lhe dê uma boa ideia do que os está abrindo e deixando abertos.
Responder3
Adicionar a seguinte linha ao xdebug.ini também resolveu o problema para mim
xdebug.remote_autostart = 0
Responder4
Estou recebendo 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 resolva realmente o problema, você pode contê-lo definindo a configuração Apache MaxRequestsPerChild para algo como 10 - o que deve ser adequado para 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 dos arquivos vazados