I'm setting up xdebug for php within sublime text, and xdebug keeps on logging errors related to being unable to connect:
Log opened at 2016-08-18 21:06:01
I: Connecting to configured address/port: localhost:9988.
E: Could not connect to client. :-(
Log closed at 2016-08-18 21:06:01
xdebug.remote_mode = req
xdebug.idekey = sublime.xdebug
apt-cache policy php-xdebug
*** 2.4.0-5+donate.sury.org~trusty+1 0
500 http://ppa.launchpad.net/ondrej/php/ubuntu/ trusty/main amd64 Packages
php -m | grep -i xdebug
PHP debugging requires two components that collaborate: a PHP extension that acts as server and a software that knows how to talk to this extension and drive its functionality (it is the client).
However, despite the usual client-server protocols where the client connects to the server, the PHP debugger works the other way around: the server is the one that connects to the client (that should be started and listening on port
xdebug is the most known PHP extension for debug. There are many programs and program extensions/plugins that acts as clients for it. I didn't work with Xdebug package for Sublime (I didn't work with Sublime, in the first place) but the principles are the same.
The client software (Sublime with the Xdebug package in your case) starts listening on port
localhost, waiting for the server to start the connection. It probably doesn't listen on the port all the time but only when the developer tells it so.
You start the PHP script to debug.
xdebug doesn't kick in on all requests to the server but only when it founds a marker in the request. Depending on the SAPI used to run the script, the marker is either an environment variable (for CLI scripts) or a cookie or a
POST argument (for web pages). Read more on the "Starting The Debugger" section of the documentation.
When the PHP interpreter starts the execution of the PHP script, if
xdebug founds the marker explained above then it tries to connect the
xdebug client. Otherwise, it stays out of the way and lets the script run at its full speed.
When the debugging marker is present in the environment, the
xdebug extension (the server) tries to connect to the
xdebug client (by default on port
localhost but these settings can be changed as needed). If it cannot connect (because the client is not listening) then it logs the failure then puts itself out of the way and lets the script run at its full speed.
After it successfully connects to the client, the
xdebug PHP extension either stops before running the first statement of the PHP script or runs the script until its execution reaches a breakpoint. This behaviour and the list of breakpoints are sent by the client to the server during their initial communication as the connection was established. Then the extension waits for commands from the client. The client displays to the developer the current state of the running script (the next statement to run, the values of the variables in the current scope etc) and waits for commands (run next statement, continue, add/remove breakpoints, watch some variable etc).
It's not very clear for me from your question but I'll assume you run the webserver (with the PHP interpreter and the
xdebug extension) on the same computer you run the
xdebug client (
localhost). If this is not the case, don't despair. The solution is a command line away (read at the end of the answer).
From the information you posted in the question is clear that
xdebug is installed, enabled and it works properly. The output of
telnet localhost 9988 says nobody is listening on port
xdebug client should listen there.
I never worked with Sublime Text (and its packages). This article explains how to install and make it work. However, it doesn't explain how to configure it to listen on port
I would start by setting the PHP
xdebug extension to connect to the default port (
and then, if everything works, I would try to find out how to configure the Sublime Text
xdebug package to listen on a different port. Do you really need it to listen on a different port?
xdebugclient are on different computers?
If you need to debug a PHP script that runs on a remote machine the
xdebug client listens on the local machine (on port
9000) and the
xdebug extension tries to connect to port
9000 on the remote machine. A solution that is possible in intranets and VPNs is to configure
xdebug to connect to port
9000 of the local machine but, apart from these conditions, it usually also requires changes in the firewall and/or other security software.
The easiest way to debug the PHP scripts in this situation if you have
ssh access to the remote machine is to create a
ssh tunnel from port
9000 of the remote machine to port
9000 of the local machine.
Assuming you use
ssh to connect to the remote machine (to put the files on it), all you have to do is to append
-R 9000:localhost:9000 to the command line you use to connect and start a
ssh session to the remote machine.
As long as this connection is open, any connection request on port
9000 (the first
9000 on the command line above) of the remote machine (
-R) is forwarded through the tunnel to the port
9000 (the second
9000 from the command line) of the local machine (
localhost). This way the remote
xdebug PHP extension is able to contact the remote
xdebug client (assuming it is listening).