"Zu viele Dateien öffnen" unter Mac OSX, nachdem Apache in PHP mit XDebug einige Zeit ausgeführt wurde
7588
Daniel Rotter
Ich verwende Mac OS X 10.9.4, einschließlich des eingebauten apache2-Webservers mit PHP 5.5.14 von brew (Pakete: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).
Wenn Sie dieses Setup ausführen, funktioniert es ziemlich gut. Nach einiger Zeit werde ich jedoch für jede Anforderung 403 Fehler ausführen. Ich habe das Apache-Fehlerprotokoll nachgeschlagen und Folgendes gefunden:
[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. () /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. () /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
Mir scheint, dass die Datei nicht mehr gelesen werden kann, und die 403 wird irgendwie zurückgegeben. Ich habe bereits einige Grenzen kennen gelernt, aber launchctl gibt zurück, dass ich ein unbegrenztes Limit für offene Dateien habe:
Ich habe auch schon versucht, die maxfiles mit dem Befehl auf 4096 zu setzen launchctl limit maxfiles 4096 16384, aber das Problem wird nach einiger Zeit immer noch angezeigt . Irgendeine Idee, was ich sonst noch überprüfen kann?
UPDATE : Beim Ausführen des lsof -c httpdBefehls, wie von Gordon Davisson vorgeschlagen, kann ich feststellen, dass es viele Einträge wie die folgenden gibt:
Ich kann sagen, dass die Anwendung, die ich verwende, Websockets verwendet und auch einen Fallback verwendet, wenn Websockets nicht verfügbar sind oder das Gegenstück nicht auf dem Server ausgeführt wird. Was mich verwirrt, ist der Teil (CLOSED), warum ist er immer noch aufgeführt?
UPDATE : Nach einiger Zeit habe ich nach dem cslistener-Port gesucht, der eigentlich 9000 ist. Dies ist wiederum der Port, der von xdebug auf Remote-Debugging überwacht wird. Ich denke, ich habe dort eine falsche Konfiguration, oder es ist ein Fehler in xdebug (ich verwende XDebug 2.2.5, installiert von brew)
Stellen Sie sicher, dass Sie mit diesem Patch eine aktualisierte Version verwenden .
Nicht wirklich eine Lösung, aber ich denke, es beantwortet die Frage
Daniel Rotter vor 9 Jahren
0
Grundsätzlich gibt Xdebug Dateideskriptoren für Verbindungslistener aus (Entschuldigung, wenn dies technisch nicht korrekt ist, ist die Idee), wenn der Debugging-Client nicht geöffnet ist. Stellen Sie zur Behebung des Problems sicher, dass der Debugger-Client geöffnet ist, wenn der Remote-Debugger eine Debugging-Sitzung startet. Eine bessere Lösung wäre natürlich eine Behebung des Fehlers durch die Entwickler.
mcdado vor 9 Jahren
0
Dies geschieht auch bei einigen geöffneten Debuggern (zum Beispiel PhpStorm). Hoffentlich werden sie es beheben :)
Steve Tauber vor 9 Jahren
0
Dies ist ziemlich wichtig, ich hoffe, dass bald ein Fix herausgegeben wird.
Hubert Perron vor 9 Jahren
0
Eine andere Problemumgehung besteht darin, `xdebug.remote_enable = 0` in` php.ini` so einzustellen, dass xdebug-Remote-Verbindungen deaktiviert werden, wenn sie nicht verwendet werden. Apache-Neustart erforderlich.
Gregory Cosmo Haun vor 8 Jahren
1
Ich arbeite mit 2.4.0 und habe immer noch Probleme mit PHP 5.6
Jeff vor 8 Jahren
0
7
Gordon Davisson
Ich bin ziemlich sicher, dass Sie etwas im Apache laufen lassen (wahrscheinlich das PHP-Modul, aber es ist schwer zu wissen), dass Dateideskriptoren auslaufen. Das heißt, es öffnet Dateien und lässt sie dann unbegrenzt offen. Wenn dies der Fall ist, dauert das Erhöhen des Limits für offene Dateien nur länger, um das Limit zu erreichen. Was Sie wirklich tun müssen, ist, zu ermitteln, was alle Dateien öffnet und offen lässt.
Sie können wahrscheinlich mit dem lsofBefehl ("LiSt Open Files") eine Vorstellung davon bekommen, was los ist :
sudo lsof -c httpd
Führen Sie es aus, wenn der Apache nicht mehr lange läuft, um zu sehen, was normal ist, und dann, wenn er das Limit erreicht. Suchen Sie in der zweiten Ausgabe nach vielen zusätzlichen Dateien, die nicht in der ersten Auflistung enthalten sind. Beachten Sie, dass dies durch die Tatsache, dass die von allen httpd-Prozessen geöffneten Dateien aufgelistet werden, etwas kompliziert wird. Je nach Apache-Einstellungen und Serverlast gibt es möglicherweise eine große Anzahl von Dateien . Das Wichtigste ist die Anzahl der Dateien, die von einem einzigen Prozess geöffnet werden, nicht die Gesamtzahl aller Serverprozesse. Sie können auch jeweils sudo lsof -p someprocessIDnur einen Serverprozess auflisten.
Wenn Sie sehen, was die extra geöffneten Dateien sind, erhalten Sie eine gute Vorstellung davon, was sie öffnet und geöffnet lässt.
Habe es ausprobiert, ich habe die Frage aktualisiert.
Daniel Rotter vor 10 Jahren
0
Ich bin mit der genauen Bedeutung der TCP-Socket-Zustände nicht sehr vertraut, aber es klingt für mich, als würden die Verbindungen zum Gegenüber nicht ordnungsgemäß geschlossen. Läuft das auf dem cslistener-Port (Nummer 9000)? Wie genau schließt Ihre App die Verbindungen zum Gegenüber? Ist es möglich, dass die TCP-Sitzung geschlossen wird, nicht aber der Dateideskriptor?
Gordon Davisson vor 10 Jahren
0
Ich habe herausgefunden, dass 9000 der Port ist, auf den xdebug wartet. Ist es möglich, dass der Fehler in dieser Erweiterung liegt?
Daniel Rotter vor 10 Jahren
1
3
Femi Veys
Das Hinzufügen der folgenden Zeile zu xdebug.ini löste das Problem auch für mich
xdebug.remote_autostart = 0
1
barryp
Mit OSX 10.9.4 und Apache 2.2 und PHP 5.3 bekomme ich dasselbe von Brew.
Das Problem kann zwar nicht behoben werden, Sie können es jedoch enthalten, indem Sie die Einstellung für Apache MaxRequestsPerChild auf etwa 10 setzen. Dies sollte für die Entwicklung gut sein.