"Demasiados archivos abiertos" en Mac OSX después de ejecutar apache en PHP con XDebug durante algún tiempo

13

Estoy ejecutando Mac OS X 10.9.4, incluido el servidor web incorporado apache2 con PHP 5.5.14 de brew (paquetes: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

Al ejecutar esta configuración, funciona bastante bien. Sin embargo, después de algún tiempo, ejecutaré 403 errores por cada solicitud. He buscado el registro de errores de apache y he encontrado 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 devuelve que tengo un límite estricto ilimitado en los 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 he intentado establecer los maxfiles en 4096 con el comando launchctl limit maxfiles 4096 16384, pero el problema aún regresa después de un tiempo. ¿Alguna idea de qué más puedo consultar?

ACTUALIZACIÓN : 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 está usando WebSockets, y también está utilizando un recurso alternativo cuando WebSocket no está disponible o la contraparte no se está ejecutando en el servidor. Lo que me confunde es la parte (CLOSED), ¿por qué sigue en la lista?

ACTUALIZACIÓN : Después de un tiempo busqué el puerto cslistener, que en realidad es 9000, que de nuevo es qué puerto xdebug está escuchando para la depuración remota. Así que supongo que tengo una configuración incorrecta allí, o es un error en xdebug (estoy usando XDebug 2.2.5, instalado por brew)

macos apache-http-server php xdebug Daniel Rotter
fuente

Respuestas:

14

¿Estás utilizando 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 ahora se ha solucionado:

Acabo de fusionar un parche de Sean Dubois, que debería solucionar esto \ o /! El parche estará en 2.3.4 y 2.4.0.

Creo que este es el commit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Asegúrese de estar utilizando una versión actualizada con este parche.

Steve Tauber
fuente
Realmente no es una solución, pero creo que responde la pregunta
Daniel Rotter
Básicamente, Xdebug está filtrando descriptores de archivos para los oyentes de conexión (perdón si esto es técnicamente incorrecto, esa es la idea) cuando el cliente de depuración no está abierto. Para resolver el problema, asegúrese de que el cliente del depurador esté abierto cuando el depurador remoto inicie una sesión de depuración. Por supuesto, una solución mejor sería una solución al error por parte de los desarrolladores.
mcdado
Esto también sucede con algunos depuradores abiertos (por ejemplo, PhpStorm). Esperemos que lo arreglen :)
Steve Tauber
Esto es bastante importante, espero que se publique una solución pronto.
Hubert Perron el
1
Otra solución consiste en establecer xdebug.remote_enable=0en php.inia su vez de las conexiones remotas Xdebug cuando no usarlos. Se requiere reiniciar Apache.
Gregory Cosmo Haun
7

Estoy bastante seguro de que tiene algo ejecutándose en Apache (probablemente el módulo PHP, pero es difícil estar seguro) que está filtrando descriptores de archivos. Es decir, está abriendo archivos y luego dejándolos abiertos indefinidamente. Si este es el caso, aumentar el límite de archivos abiertos solo demora más en alcanzar el límite. Lo que realmente necesita hacer es localizar qué está abriendo todos los archivos y dejarlos abiertos.

Probablemente pueda hacerse una idea de lo que está sucediendo con el lsofcomando ("LiSt Open Files"):

sudo lsof -c httpd

Ejecútelo cuando Apache no se haya estado ejecutando durante mucho tiempo para ver qué es normal, y nuevamente cuando llegue al límite. Busque en la segunda salida muchos archivos adicionales que no están en la primera lista. Tenga en cuenta que esto será algo complicado por el hecho de que enumerará los archivos abiertos por todos los procesos 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 en todos los procesos del servidor. También puede usar 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 lo que los abre y los deja abiertos.

Gordon Davisson
fuente
Probé, actualicé la pregunta.
Daniel Rotter
No estoy muy familiarizado con el significado exacto de los estados del socket TCP, pero me parece que las conexiones a la contraparte no se están cerrando correctamente. ¿Se está ejecutando en el puerto cslistener (número 9000)? ¿Cómo cierra exactamente su aplicación las conexiones a su contraparte? ¿Es posible que cierre la sesión TCP, pero no el descriptor de archivo?
Gordon Davisson
1
Descubrí que 9000 es el puerto en el que escucha xdebug, entonces, ¿es posible que el error esté en esta extensión?
Daniel Rotter
3

Agregar la siguiente línea a xdebug.ini también me resolvió el problema

xdebug.remote_autostart = 0
Femi Veys
fuente
1

Estoy obteniendo 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, 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 evitar al menos tener que reiniciar Apache de vez en cuando para deshacerse de esos archivos filtrados

barryp
fuente