View Issue Details

IDProjectCategoryView StatusLast Update
0001070XdebugUncategorizedpublic2015-11-05 15:08
Reportervirtustilus Assigned Toderick  
Status closedResolutionfixed 
PlatformUnixOSMac OS XOS Version10.9.4
Product Version2.2.5 
Fixed in Version2.4.0beta1 
Summary0001070: Too many open files error with php-fpm. Connection not closed.

Installed next software with homebrew:

  • PHP 5.5.15 (cli) (built: Aug 11 2014 09:24:23).
  • PHP 5.5.15 (fpm-fcgi) (built: Aug 11 2014 09:24:29)
  • php55-xdebug 2.2.5
  • nginx version: nginx/1.6.1

Checking that by command:

sudo lsof -i TCP:9000

When some PHP script opened from web via PHP-FPM it's adding new line into output of lsof like:

php-fpm 91212 virtustilus 5u IPv4 0xc1a6a41a2fd69fab 0t0 TCP localhost:55660->localhost:9000 (CLOSED)

After some time I get error from php-fpm "Too many open files".
Tried to enlarge count of available open files up to 8192:

ulimit -a

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 8192
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 709
virtual memory (kbytes, -v) unlimited

It's help for some time but later I get this error again.

When I start some script from CLI it's adding new one connection while script is working and after the end of script this connection disappearing from lsof output.

I've tried to install new version of xdebug by "pecl install xdebug", but got the same problem with new compiled version.

Also I've found temporary workaround for this issue!
in "php-fpm.conf" set parameter "pm.max_requests = 10" (just limit to some number). And after this count of requests each children process will respawn and his opened connections also closed.

Steps To Reproduce

Install php55, php55-fpm, php55-xdebug, nginx with homebrew.
Configure nginx with php-fpm.
Run "sudo lsof -i TCP:9000" and ensure that you have not any connection.
Open 100 times some php script via, for example, "curl http://localhost/some.php"
Run "sudo lsof -i TCP:9000" again.
Repeat opening "curl http://localhost/some.php" many times and get error "Too many open files"

Additional Information

Xdebug config:


xdebug.default_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_connect_back = 1
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_port = 9000
xdebug.remote_host = ""
xdebug.max_nesting_level = 350
xdebug.idekey = "PHPSTORM"

TagsNo tags attached.
Operating SystemMac OS X 10.9 Mavericks
PHP Version5.5.5-5.5.9



2014-10-06 14:22

reporter   ~0002883

hi, I've experienced a similar problem with apache+mod_php, and unfortunatelly I couldn't see first that the fd leaks are coming from xdebug, because netstat//proc/net* wasn't showing the tcp connection and lsof was only showing sock sockets with "can't identify protocol", this seems to be the expected behavior on some/all Linuces( instead of showing CLOSE_WAIT status.

unfortunatelly I can't reprodece the problem atm, but my impression is that my PHPStorm was acting up and not (properly) accepting/responding to the incoming remote debug connection which caused xdebug to not properly close the file handles, as we will only close the connection when XG(remote_enabled) returns 1:
but we only set that to 1 when the connection was opened and initialized properly:


2014-10-21 10:16

reporter   ~0002886

I have this same problem.

$ php -v
PHP 5.4.30 (cli) (built: Jun 28 2014 01:54:14)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans

I also use PHPStorm on my Mac OS X 10.9.5

$ lsof | grep cslistener | wc -l

examples from lsof | grep cslistener:

httpd 72406 stevetauber 43u IPv4 0xc725cbc35b728fc5 0t0 TCP localhost:60985->localhost:cslistener (CLOSED)
httpd 72406 stevetauber 44u IPv4 0xc725cbc353c6b7ad 0t0 TCP localhost:60986->localhost:cslistener (CLOSED)

$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 1
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 709
virtual memory (kbytes, -v) unlimited

Xdebug config:


PhpStorm 8.0.1
Build #PS-138.2001, built on September 18, 2014
JRE: 1.6.0_65-b14-462-11M4609 x86_64


2014-10-21 17:11

reporter   ~0002887

This is definitely an issue independent of PHPStorm. I closed PHPStorm and used curl to hit my server. Without ?XDEBUG_SESSION_START=php set, then the sessions are closed correctly. With ?XDEBUG_SESSION_START=php set then the sessions stay open. I'd be happy to troubleshoot with someone if needed.


2014-11-06 23:07

reporter   ~0002888

This also occurs for me with a simple Apache + PHP 5.4.33 setup on OS X Mavericks 10.9 and OS X Yosemite 10.10.

If I enable remote_autostart but don't have a debugger running to accept the connection, a new connection is created on each execution which doesn't get closed. Running sudo lsof -i TCP:9000, there are a bunch of entries like the following:

httpd 2886 henry 136u IPv4 0x9e566f69412d37cd 0t0 TCP localhost:60817->localhost:cslistener (CLOSED)
httpd 2886 henry 137u IPv4 0x9e566f69412d2efd 0t0 TCP localhost:60818->localhost:cslistener (CLOSED)
httpd 2886 henry 138u IPv4 0x9e566f694145109d 0t0 TCP localhost:61210->localhost:cslistener (CLOSED)
httpd 2886 henry 139u IPv4 0x9e566f694137962d 0t0 TCP localhost:61008->localhost:cslistener (CLOSED)

If I reboot apache they go away and everything is fine again.

If I do have a debugger running, the connections are dealt with normally, and there is no issue.


2014-11-14 10:39

reporter   ~0002911

This happens with OS X 10.9 Mavericks, OS X 10.10 Yosemite, with PHP ranging from 5.3 to 5.6 installed via homebrew, with the OSX default Apache that comes preinstalled.

As henrys mentions in the last comment, by disabling xdebug.remote_enable in the conf file, you can see (lsof -i TCP:9000) that no listeners are "leaked". If you enable the remote debugger, then there is leakage whenever a new session is started without the client being opened.

If you enable xdebug.remote_autostart, then it's on every connection while you don't have a client open, otherwise it's only when you send the XDEBUG_SESSION_START parameter without the client open.

This is quite major.


2015-01-05 13:18

reporter   ~0002956

Last edited: 2015-01-10 07:50

I'm also getting this on Apache 2.4 now, PHP 5.5.20

I'm attempting to alleviate the issue by only enabling remote_enable with an Apache 2.4 <If> statement.

EDIT Gentoo Linux


2015-01-09 16:39

reporter   ~0002966

Last edited: 2015-01-10 11:37

Confirming report 0001070:0002888.

xdebug 2.2.6
Mac OS X 10.10 Yosemite
PHP 5.6.4
Apache 2.4.9


2015-01-09 23:12

administrator   ~0002967

Can any of you reproduce this with Linux? Because, I have just tried and I can't see any issues.

I have done the following:

  • Installed a clean new VirtualBox environment for Ubuntu 14.10

  • Installed nginx and php as per

  • Installed Xdebug, and set xdebug.remote_connect_back and xdebug.remote_enable to 1 so that it connects to my host, running (or not running phpstorm)

  • Set xdebug.remote_log=/tmp/remote.log

  • phpstorm sees incoming connections and I can debug

  • if phpstorm is not running, then /tmp/remote.log reflects that, but no connections are piling up doing "sudo lsof | grep cslistener" on the guest VM


2015-01-10 07:50

reporter   ~0002968

Edited my note above. I'm Gentoo Linux


2015-01-10 11:47

administrator   ~0002969

OK - but I still need an accurate way to reproduce this. If you have a Vagrant setup, or a VirtualBox instance, or something where I can log into and run a debugger... all helpful. Having a way to reproduce it myself is best though. Right now, I don't know where to begin.


2015-01-26 20:25

reporter   ~0002974

@lkraav, can you provide some more info about which version Gentoo you are using? Alternatively if you have time to build a vagrant setup that would be great :)

@derick: So far everyone has had this problem using apache. Could you try with Apache?

I tried setting up a gentoo vagrant box for you but ran into problems. I'll try again later this week. If you can find a base image for a Mac, I could try to set that up to but I'm not sure that exists.


2015-01-27 07:29

reporter   ~0002976

I'm seeing a similar problem on CentOS 7


Using mod_proxy_fcgi (locally packaged) with the unix domain socket patch for the FastCGI connection.

In my case connections appear to leak when the debug client accepts, then closes the connection during the request (stop or detach).

I have users using both PHP Storm and Vdebug (vim plugin), although I've only been able to confirm the problem against Vdebug so far.


2015-02-13 15:47

reporter   ~0002986

@stevetauber gentoo doesn't have versions, it's a rolling distribution.

i'm currently on apache-2.4.10 and xdebug-2.2.7. As soon as we leave the cookie activated for too long and work on sites, pretty soon the server will get flooded with

Feb 13 17:21:57 gusto apache2[1673]: create_debugger_socket("localhost", 9011) socket: Too many open files


2015-02-13 15:51

reporter   ~0002987

@Ikraav: cat /etc/gentoo-release please :)


2015-02-13 16:07

reporter   ~0002988

L kraav ;) i know, it's really hard to detect from the font.

$ [-] cat /etc/gentoo-release
Gentoo Base System release 2.2

not sure what exactly this gives you though. gentoo currently only has one sys-apps/baselayout package in the tree that everything runs on.


2015-02-13 16:09

reporter   ~0002989

Ahhhh so sorry. But thank you :)

I'm gentoo dumb so it gives me a starting point :)


2015-02-21 00:27

reporter   ~0002996

Same issue with apache/centos 6.5:

centos-release.x86_64 6-5.el6.centos.11.1
httpd.x86_64 2.2.15-39.el6.centos


PHP 5.5.18 (cli) (built: Oct 16 2014 20:56:12)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2014, by Zend Technologies
with Xdebug v2.2.5, Copyright (c) 2002-2014, by Derick Rethans


2015-06-01 11:12

reporter   ~0003103

Confirmed on Mac OS X 10.10.3. Issue is not resolved.

PHP 5.5.24 installed with Homebrew. Xdebug 2.3.2. Can someone expand the affected version? Can also reproduce with PHP 5.6. I am using the built in server for development.

Debugging is almost impossible as it is right now. Also using PHP Storm (latest stable). Anyone find a workaround for the short term?


2015-06-14 02:16

reporter   ~0003117

The workaround I use is to turn off autostart:

xdebug.remote_autostart = 0

Then in Firefox install the Add-on called The Easiest XDebug

In PHPStorm turn on the listener when you want to debug. It won't break unless you click the bug icon in the Firefox toolbar. You might get some errors if you leave the listener on in PHPStorm so turn it off when you're not using it.


2015-08-03 14:04

reporter   ~0003156



2015-08-03 15:56

reporter   ~0003157

I finally gave up on xdebug and switched to Zend Debugger. It's not as good as xdebug (no skipping), but it works without a flaw. I recommend uninstalling xdebug from any production servers you might have it on without realizing it. Even if it is not enabled.


2015-11-04 10:36

administrator   ~0003199

I just merged a patch by Sean Dubois, which should fix this \o/! The patch is going to be in 2.3.4 and 2.4.0.

Issue History

Date Modified Username Field Change
2014-08-19 20:25 virtustilus New Issue
2014-10-06 14:22 Tyrael Note Added: 0002883
2014-10-21 10:16 stevetauber Note Added: 0002886
2014-10-21 17:11 stevetauber Note Added: 0002887
2014-11-06 23:07 henrys Note Added: 0002888
2014-11-14 10:39 mcdado Note Added: 0002911
2015-01-05 13:18 lkraav Note Added: 0002956
2015-01-09 16:39 wellebee Note Added: 0002966
2015-01-09 23:12 derick Note Added: 0002967
2015-01-10 07:50 lkraav Note Edited: 0002956
2015-01-10 07:50 lkraav Note Added: 0002968
2015-01-10 11:37 wellebee Note Edited: 0002966
2015-01-10 11:47 derick Note Added: 0002969
2015-01-26 20:25 stevetauber Note Added: 0002974
2015-01-27 07:29 Trav Note Added: 0002976
2015-02-13 15:47 lkraav Note Added: 0002986
2015-02-13 15:51 stevetauber Note Added: 0002987
2015-02-13 16:07 lkraav Note Added: 0002988
2015-02-13 16:09 stevetauber Note Added: 0002989
2015-02-21 00:27 cgeisel Note Added: 0002996
2015-06-01 11:12 asentner Note Added: 0003103
2015-06-14 02:16 vnyx Note Added: 0003117
2015-08-03 14:04 xpersonas Note Added: 0003156
2015-08-03 15:56 vnyx Note Added: 0003157
2015-11-04 10:36 derick Note Added: 0003199
2015-11-04 10:36 derick Status new => closed
2015-11-04 10:36 derick Assigned To => derick
2015-11-04 10:36 derick Resolution open => fixed
2015-11-04 10:36 derick Fixed in Version => 2.3.4
2015-11-05 15:08 derick Fixed in Version 2.3.4 => 2.4.0beta1
2016-07-31 12:36 derick Category Usage problems => Usage problems (Crashes)
2016-07-31 12:38 derick Category Usage problems (Crashes) => Usage problems (Wrong Results)
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized