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(https://idea.popcount.org/2012-12-09-lsof-cant-identify-protocol/) 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:
https://github.com/xdebug/xdebug/blob/7f02f003bbb975019f6382ebae9f0b64b8d59e56/xdebug.c#L989
but we only set that to 1 when the connection was opened and initialized properly:
https://github.com/xdebug/xdebug/blob/4cac5152e2d5ed6dbbd779a72b28035f22e002a3/xdebug_stack.c#L493

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
1625

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:

zend_extension=/opt/local/lib/php54/extensions/no-debug-non-zts-20100525/xdebug.so
xdebug.remote_enable=true

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

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.

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.

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.

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

Confirming report 0001070:0002888.

xdebug 2.2.6
Mac OS X 10.10 Yosemite
PHP 5.6.4
Apache 2.4.9

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 https://www.digitalocean.com/community/tutorials/how-to-install-linux-nginx-mysql-php-lemp-stack-on-ubuntu-12-04

• 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

Edited my note above. I'm Gentoo Linux

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.

@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.

I'm seeing a similar problem on CentOS 7

centos-release-7-0.1406.el7.centos.2.5.x86_64
httpd-2.4.6-18.el7.centos.x86_64
php-fpm-5.4.16-23.el7_0.3.x86_64
php-pecl-xdebug-2.2.6-1.el7.x86_64

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.

@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
...

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

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.

Ahhhh so sorry. But thank you :)

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

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/xdebug:

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

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?

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.

-

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.

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.