«Trop de fichiers ouverts» sur Mac OSX après avoir exécuté apache en PHP avec XDebug pendant un certain temps

13

J'utilise Mac OS X 10.9.4, y compris le serveur Web intégré apache2 avec PHP 5.5.14 de brew (packages: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

Lorsque vous exécutez cette configuration, cela fonctionne très bien. Cependant, après un certain temps, je vais exécuter 403 erreurs pour chaque demande. J'ai recherché le journal des erreurs apache et trouvé quelque chose comme ceci:

[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

Il me semble que le fichier ne peut plus être lu, et il renvoie le 403 d'une manière ou d'une autre. J'ai déjà découvert certaines limites, mais launchctl retourne que j'ai une limite fixe illimitée sur les fichiers ouverts:

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

J'ai également déjà essayé de définir les maxfiles à 4096 avec la commande launchctl limit maxfiles 4096 16384, mais le problème revient toujours après un certain temps. Une idée de quoi d'autre je peux vérifier?

MISE À JOUR : Lors de l'exécution de la lsof -c httpdcommande comme suggéré par Gordon Davisson, je peux voir qu'il y a beaucoup d'entrées comme les suivantes:

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

Je peux dire que l'application que j'utilise utilise des websockets et utilise également une solution de secours lorsque les websockets ne sont pas disponibles ou que l'homologue ne s'exécute pas sur le serveur. Ce qui m'embrouille c'est le (CLOSED)-part, pourquoi est-il toujours listé?

MISE À JOUR : Après un certain temps, j'ai recherché le port cslistener, qui est en fait 9000, qui est à nouveau le port que xdebug écoute pour le débogage à distance. Donc je suppose que j'ai une mauvaise configuration, ou c'est un bogue dans xdebug (j'utilise XDebug 2.2.5, installé par brew)

macos apache-http-server php xdebug Daniel Rotter
la source

Réponses:

14

Utilisez-vous PHPStorm avec XDEBUG sur Mac?

J'ai le même problème. J'ai trouvé un bogue ouvert déposé auprès de XDEBUG ici:

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

Mise à jour

Ce bug a maintenant été corrigé:

Je viens de fusionner un patch de Sean Dubois, qui devrait corriger ce \ o /! Le patch va être en 2.3.4 et 2.4.0.

Je crois que c'est le commit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Assurez-vous que vous utilisez une version mise à jour avec ce correctif.

Steve Tauber
la source
Pas vraiment une solution, mais je pense que cela répond à la question
Daniel Rotter
Fondamentalement, Xdebug perd des descripteurs de fichiers pour les écouteurs de connexion (désolé si c'est techniquement incorrect, c'est l'idée) lorsque le client de débogage n'est pas ouvert. Pour résoudre le problème, assurez-vous que le client du débogueur est ouvert lorsque le débogueur distant démarre une session de débogage. Bien sûr, une meilleure solution serait une correction du bogue par les développeurs.
mcdado
Cela se produit également avec certains débogueurs ouverts (par exemple PhpStorm). J'espère qu'ils le répareront :)
Steve Tauber
C'est assez important, j'espère qu'un correctif sera publié bientôt.
Hubert Perron
1
Une autre solution consiste à définir xdebug.remote_enable=0dans php.inipour activer des connexions à distance de Xdebug lorsqu'ils ne sont pas les utiliser. Redémarrage d'Apache requis.
Gregory Cosmo Haun
7

Je suis sûr que vous avez quelque chose en cours d'exécution dans Apache (probablement le module PHP, mais il est difficile d'être sûr) qui fuit les descripteurs de fichiers. Autrement dit, il ouvre des fichiers, puis les laisse ouverts indéfiniment. Si tel est le cas, l'augmentation de la limite de fichiers ouverts ne fait que prendre plus de temps pour atteindre la limite. Ce que vous devez vraiment faire, c'est localiser ce qui ouvre tous les fichiers et les laisser ouverts.

Vous pouvez probablement avoir une idée de ce qui se passe avec la commande lsof("LiSt Open Files"):

sudo lsof -c httpd

Exécutez-le quand apache n'a pas fonctionné depuis longtemps pour voir ce qui est normal, puis à nouveau quand il atteint la limite. Recherchez dans la deuxième sortie de nombreux fichiers supplémentaires qui ne figurent pas dans la première liste. Notez que cela sera quelque peu compliqué par le fait qu'il listera les fichiers ouverts par tous les processus httpd, et (en fonction de vos paramètres Apache et de la charge du serveur) il peut y en avoir un grand nombre; l'important est le nombre de fichiers ouverts par un seul processus, pas le total sur tous les processus serveur. Vous pouvez également utiliser sudo lsof -p someprocessIDpour répertorier un seul processus serveur à la fois.

Espérons que voir quels sont les fichiers ouverts supplémentaires vous donnera une bonne idée de ce qui les ouvre et les laisse ouverts.

Gordon Davisson
la source
Je l'ai essayé, j'ai mis à jour la question.
Daniel Rotter
Je ne connais pas très bien la signification exacte des états de socket TCP, mais il me semble que les connexions à l'homologue ne se ferment pas correctement. Est-ce que cela fonctionne sur le port cslistener (numéro 9000)? Comment votre application ferme-t-elle exactement les connexions à son homologue? Est-il possible que cela ferme la session TCP, mais pas le descripteur de fichier?
Gordon Davisson
1
J'ai découvert que 9000 est le port que xdebug écoute, est-il possible que l'erreur se trouve dans cette extension?
Daniel Rotter
3

L'ajout de la ligne suivante à xdebug.ini a également résolu le problème pour moi

xdebug.remote_autostart = 0
Femi Veys
la source
1

J'obtiens la même chose avec OSX 10.9.4 et Apache 2.2 et PHP 5.3 de Brew.

Bien que cela ne résout pas réellement le problème, vous pouvez le contenir en définissant le paramètre Apache MaxRequestsPerChild sur quelque chose comme 10 - ce qui devrait être bien pour le développement.

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

Cela devrait vous éviter au moins d'avoir à redémarrer apache de temps en temps pour vous débarrasser de ces fichiers qui ont fui.

barryp
la source