"Troppi file aperti" su Mac OSX dopo aver eseguito apache in PHP con XDebug per qualche tempo

13

Sto eseguendo Mac OS X 10.9.4, incluso il webserver integrato apache2 con PHP 5.5.14 di brew (pacchetti: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

Quando si esegue questa configurazione funziona abbastanza bene. Tuttavia, dopo qualche tempo, eseguirò 403 errori per ogni richiesta. Ho cercato il registro degli errori di Apache e ho trovato qualcosa di simile al seguente:

[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

Mi sembra che il file non possa più essere letto e in qualche modo restituisce il 403. Ho già scoperto alcuni limiti, ma launchctl restituisce un limite rigido illimitato per i file aperti:

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

Ho anche già provato a impostare i maxfile su 4096 con il comando launchctl limit maxfiles 4096 16384, ma il problema ritorna ancora dopo qualche tempo. Hai idea di cos'altro posso controllare?

AGGIORNAMENTO : Quando eseguo il lsof -c httpdcomando come suggerito da Gordon Davisson, posso vedere che ci sono un sacco di voci come la seguente:

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

Posso dire che l'applicazione che utilizzo utilizza websocket e utilizza anche un fallback quando i websocket non sono disponibili o la controparte non è in esecuzione sul server. Ciò che mi confonde è la (CLOSED)parte, perché è ancora elencata?

AGGIORNAMENTO : Dopo qualche tempo ho cercato la porta cslistener, che in realtà è 9000, che è di nuovo quella porta che xdebug è in ascolto per il debug remoto. Quindi immagino di avere una configurazione errata lì, o è un bug in xdebug (sto usando XDebug 2.2.5, installato da brew)

macos  apache-http-server  php  xdebug 
— Daniel Rotter
fonte

Risposte:

14

Stai usando PHPStorm con XDEBUG su Mac?

Ho lo stesso problema. Ho trovato un bug aperto archiviato con XDEBUG qui:

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

Aggiornare

Questo bug è stato ora corretto:

Ho appena unito una patch di Sean Dubois, che dovrebbe risolvere questo \ o /! La patch sarà in 2.3.4 e 2.4.0.

Credo che questo sia il commit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Assicurati di utilizzare una versione aggiornata con questa patch.

— Steve Tauber
fonte
Non è davvero una soluzione, ma penso che risponda alla domanda
— Daniel Rotter,
Fondamentalmente, Xdebug perde descrittori di file per i listener di connessione (scusate se questo è tecnicamente errato, questa è l'idea) quando il client di debug non è aperto. Per risolvere il problema, assicurarsi che il client debugger sia aperto quando il debugger remoto avvia una sessione di debug. Naturalmente, una soluzione migliore sarebbe una correzione del bug da parte degli sviluppatori.
— mcdado,
Questo succede anche con alcuni debugger aperti (ad esempio PhpStorm). Spero che lo risolvano :)
— Steve Tauber,
Questo è piuttosto importante, spero che presto venga pubblicata una correzione.
— Hubert Perron,
1
Un'altra soluzione è impostato xdebug.remote_enable=0in php.initrasformare di connessioni remote Xdebug quando non li utilizzano. Riavvio di Apache richiesto.
— Gregory Cosmo Haun,
7

Sono abbastanza sicuro che hai qualcosa in esecuzione in Apache (probabilmente il modulo PHP, ma è difficile essere sicuri) che sta perdendo i descrittori di file. Cioè, sta aprendo i file e poi lasciandoli aperti indefinitamente. In questo caso, aumentare il limite del file aperto fa solo impiegare più tempo per raggiungere il limite. Quello che devi veramente fare è rintracciare ciò che apre tutti i file e li lascia aperti.

Probabilmente puoi avere un'idea di cosa sta succedendo con il lsofcomando ("LiSt Open Files"):

sudo lsof -c httpd

Eseguilo quando apache non è in esecuzione da molto tempo per vedere cosa è normale, poi di nuovo quando raggiunge il limite. Cerca nel secondo output molti file aggiuntivi che non sono presenti nel primo elenco. Si noti che ciò sarà complicato dal fatto che elencherà i file aperti da tutti i processi httpd e (a seconda delle impostazioni di Apache e del carico del server) potrebbero essercene molti; l'importante è il numero di file aperti da un singolo processo, non il totale tra tutti i processi del server. È inoltre possibile utilizzare sudo lsof -p someprocessIDper elencare un solo processo server alla volta.

Spero che vedere quali siano i file extra aperti ti darà una buona idea di cosa li sta aprendo e lasciandoli aperti.

— Gordon Davisson
fonte
Ho provato, ho aggiornato la domanda.
— Daniel Rotter,
Non ho molta familiarità con il significato esatto degli stati socket TCP, ma mi sembra che le connessioni alla controparte non vengano chiuse correttamente. È in esecuzione sulla porta cslistener (numero 9000)? In che modo esattamente la tua app chiude le connessioni alla sua controparte? È possibile che stia chiudendo la sessione TCP, ma non il descrittore di file?
— Gordon Davisson,
1
Ho scoperto che 9000 è la porta su cui xdebug è in ascolto, quindi è possibile che l'errore si trovi in ​​questa estensione?
— Daniel Rotter,
3

L'aggiunta della seguente riga a xdebug.ini ha risolto anche il problema per me

xdebug.remote_autostart = 0
— Femi Veys
fonte
1

Sto ottenendo la stessa cosa con OSX 10.9.4 e sia Apache 2.2 che PHP 5.3 di Brew.

Sebbene ciò non risolva effettivamente il problema, puoi contenerlo impostando Apache MaxRequestsPerChild su qualcosa di simile a 10 - che dovrebbe andare bene per lo sviluppo.

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

Ciò dovrebbe salvarti almeno dal dover riavviare apache ogni tanto per sbarazzarti di quei file trapelati

— barryp
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.