Estoy ejecutando Mac OS X 10.9.4, incluido el servidor web Apache2 integrado con PHP 5.5.14 de Brew (paquetes: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).
Cuando se ejecuta esta configuración, funciona bastante bien. Sin embargo, después de un tiempo, ejecutaré errores 403 para cada solicitud. Busqué el registro de errores de Apache y encontré algo como lo siguiente:
[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
Me parece que el archivo ya no se puede leer y devuelve el 403 de alguna manera. Ya descubrí ciertos límites, pero launchctl regresa. Tengo un límite estricto ilimitado para archivos abiertos:
~ $ 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
También intenté configurar maxfiles en 4096 con el comando launchctl limit maxfiles 4096 16384, pero el problema persiste después de un tiempo. ¿Alguna idea de qué más puedo comprobar?
ACTUALIZAR: Al ejecutar el lsof -c httpdcomando sugerido por Gordon Davisson, puedo ver que hay muchas entradas como las siguientes:
httpd 1361 _www 15u IPv4 0xb306b48659f63853 0t0 TCP localhost:50603->localhost:cslistener (CLOSED)
Puedo decir que la aplicación que uso usa websockets y también usa un respaldo cuando los websockets no están disponibles o la contraparte no se está ejecutando en el servidor. Lo que me confunde es la (CLOSED)parte -, ¿por qué sigue en la lista?
ACTUALIZAR: Después de un tiempo busqué el puerto cslistener, que en realidad es 9000, que nuevamente es qué puerto está escuchando xdebug para la depuración remota. Así que supongo que tengo alguna configuración incorrecta allí, o es un error en xdebug (estoy usando XDebug 2.2.5, instalado por brew)
Respuesta1
¿Estás usando PHPStorm con XDEBUG en Mac?
Tengo el mismo problema. Encontré un error abierto archivado con XDEBUG aquí:
http://bugs.xdebug.org/view.php?id=1070
Actualizar
Este error ya ha sido solucionado:
¡Acabo de fusionar un parche de Sean Dubois, que debería solucionar este problema \o/! El parche estará en 2.3.4 y 2.4.0.
Creo que este es el compromiso:https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9
Asegúrate de que estásusando una versión actualizadacon este parche.
Respuesta2
Estoy bastante seguro de que tienes algo ejecutándose en Apache (probablemente el módulo PHP, pero es difícil estar seguro) que está filtrando descriptores de archivos. Es decir, abre archivos y luego los deja abiertos indefinidamente. Si este es el caso, aumentar el límite de archivos abiertos sólo hace que se tarde más en alcanzar el límite. Lo que realmente necesitas hacer es localizar qué abre todos los archivos y los deja abiertos.
Probablemente puedas hacerte una idea de lo que sucede con el lsofcomando ("LiSt Open Files"):
sudo lsof -c httpd
Ejecútelo cuando Apache no haya estado ejecutándose por mucho tiempo para ver qué es normal, y luego nuevamente cuando alcance el límite. Busque en el segundo resultado muchos archivos adicionales que no están en la primera lista. Tenga en cuenta que esto será un poco complicado por el hecho de que enumerará los archivos abiertos portodoprocesos httpd y (dependiendo de la configuración de Apache y la carga del servidor) puede haber una gran cantidad de ellos; lo importante es la cantidad de archivos abiertos por un solo proceso, no el total de todos los procesos del servidor. También puede utilizar sudo lsof -p someprocessIDpara enumerar solo un proceso de servidor a la vez.
Con suerte, ver cuáles son los archivos abiertos adicionales le dará una buena idea de qué los abre y qué los deja abiertos.
Respuesta3
Agregar la siguiente línea a xdebug.ini también resolvió el problema
xdebug.remote_autostart = 0
Respuesta4
Obtengo lo mismo con OSX 10.9.4 y Apache 2.2 y PHP 5.3 de Brew.
Si bien esto en realidad no soluciona el problema, puede contenerlo estableciendo la configuración de Apache MaxRequestsPerChild en algo así como 10, lo que debería estar bien para el desarrollo.
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
Eso debería evitarle al menos tener que reiniciar Apache de vez en cuando para deshacerse de esos archivos filtrados.