I am currently set up using xdebug, PhpStorm & Vagrant.
It works perfect, but when I am connected to the internet through a VPN, the debug page never loads, it hangs on connecting to the page.
Specifically I click Run > Debug, and Firefox browser opens and the page is blank, the tab says "Connecting..." with the spinning icon, the bottom left says "Waiting for {page address}...". PhpStorm gives no indication it is waiting for anything, it looks like it is connected in debug mode.
If I wait for about 5 minutes or more, sometimes the page does load, but it is unusable for debugging purposes, and if I click a link/refresh the page, again it is 5 minutes.
Any idea why being connected through VPN would break it like this?
Andrew, can we get a few more details about your setup?
Without knowing your specific setup, I'm going to guess that the remote PHP app may not be able to connect to port 9000 on your laptop.
Before starting your debug session, you might try setting up a reverse tunnel to allow your remote host to talk to port 9000 on your laptop.
From a command line on your laptop you would do something like the following :
ssh -R 127.0.0.1:9000:laptop-IP:9000 remoteUser#webServerIP
For example, ssh -R 127.0.0.1:9000:192.168.1.29:9000 user500#192.168.0.100
In the above example, your laptop (192.168.1.29) will be logged into the remote server (192.168.0.100) as user500 and will be able to see via the netstat command that it's listening for connections on port 9000 :
user500#192.168.0.100$ netstat -natep | grep 9000
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 500 5189077 -
tcp 0 0 ::1:9000 :::* LISTEN 500 5189076 -
Now you should be able to initiate a debug session with PhpStorm by setting xdebug.remote_host=127.0.0.1 on your remote server in php.ini .
Similarly, initiating a php debug session from the command line while logged into the remote server would look like this -
php -dxdebug.remote_host=127.0.0.1 -dxdebug.remote_enable=1 -dxdebug.remote_autostart=1 my_php_code.php
I'm running linux / CentOS on both my laptop and remote server.
Related
I have a development installation of Gatsby Doc site running on my EC2 server.
When I run the code on my dev machine it works and I can connect my browser to port 8000 and everything is ok..
On my server i check out my github code and
yarn install
npm run start.
Everything builds correctly and Gatsby it listening on port 8000
From my dev machine when I connect using
X.X.X.X:8000 in my browser i receive
Unable to connect
I have opened the port on 8000 in the firewall and I have tested that it works as expected using:
nc -lv 8000
on the server (where gatsby is going to run) and connect using telnet.
on the server i receive
Listening on [0.0.0.0] (family 0, port 8000)
Connection from 84.232.Y.Y 38552 received!
So it works.
When Gatsby is finished starting i see
You can now view gatsbyjs.org in the browser. ⠀ http://localhost:8000/
⠀
when i enter the web address and port i receive
Unable to connect
again. do I need to start Gatsby in another mode?
Kim
I found out.
I just added -H 0.0.0.0 to the start up command and everything works now.
I'm attempting to get Xdebug connecting to my PhpStorm from an EC2 instance.
I have opened up port 9000 on the security group tied to the EC2 instance.
Prior to opening it up with UDP, I would get:
telnet: connect to address <IP>: Connection refused
telnet: Unable to connect to remote host```
After opening it up, I get:
Trying <IP>... and it just hangs there.
I port forwarded 9020 internally to 9000 externally to see if that would give any different results (since I can't find a setting on the router for simply opening up ports)
My xdebug.ini setting is located at: /etc/php-5.6.d/50-xdebug.ini (yes, very old version of PHP that I have to work with here).
My xdebug.ini contains this:
xdebug.remote_autostart=on
xdebug.remote_enable=on
xdebug.idekey=PHPSTORM
xdebug.remote_connect_back = On
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode = req
I'm using PhpStorm, and have it listening on port 9020 now (tried 9000 prior to port forwarding with the same result).
I have the Xdebug browser extension installed and have it set to PHPSTORM.
I have stop on first line turned on, as well as breakpoints just in case.
Xdebug is set to listen.
When I hit the PHP page from my browser, nothing happens. I've had this working dozens of times, but never from an EC2 instance. Any idea what I missed?
I've setup debug configuration for PhpStorm and it is successfully validated by PhpStorm:
Xdebug helper for Chrome is also installed.
The problem is that nothing happens when I start listening for debug connections and reload the required page with Xdebug helper switched on. Also tried this bookmarklets with no luck.
No errors or something, just nothing.
Also tried to set different IPs as dockerhost: from 192.168.. range (from network settings), from 172.* range (from nginx), from 10.* range (10.0.75.1 is default). Also tried docker.for.mac.internal.host which failed when containers were starting.
Docker 17.02, macOS Sierra, PhpStorm 2017.3
If you're on linux, be sure to create corresponding rules in your firewall.
But to troubleshoot this more effectively you need to gather more info.
Enable xdebug logging xdebug.remote_log=/var/www/xdebug.log in you
xdebug.ini or you can append that in the "Cli Interpreters > Configuration Options" in PHPStorm (xdebug.remote_log, /path/inside/workspace/container/xdebug.log)
Another step you could take is to monitor the incoming connections to your machine. (run this on where you installed docker). It will start listening to all incoming connection attempts on port 9000.
sudo tcpdump -i any port 9000
Now run the debugger once, check the logs inside the container (workspace by default) and see if any incoming connection attempts have gone through from the container.
If you see something like Time-out connecting to client (Waited: 200 ms). :-(, chances are that your firewall is blocking the incoming connections.
To open them up you could add a rule using ufw
sudo ufw allow in from 172.22.0.0/24 to any port 9000 (or write down a specific ip) Be sure to double check that this is the ip trying to connect
this will allow all connections on port 9000 from 172.22.0.* (which is what laradock uses for its virtual networks). Be sure to double check the logs maybe your setup uses different ip range)
My working xdebug.ini (both in php-fpm and workspace containers are the same)
xdebug.remote_host=dockerhost
xdebug.remote_connect_back=0
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM
xdebug.remote_autostart=1
xdebug.remote_enable=1
xdebug.remote_log=/var/www/xdebug.log
xdebug.cli_color=1
xdebug.profiler_enable=0
xdebug.profiler_output_dir="~/path/to/profiler.log"
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.var_display_max_children=-1
xdebug.var_display_max_data=-1
xdebug.var_display_max_depth=-1
If none of the above works, another step would be to also check if you have any containers running on port 9000 already. If so, then you'll need to use another, port, just don't forget to expose it from docker.
(Explanation: docker binds (exposes) ports to the host machine so that any incoming connections get directed to the right container, if 9000 is taken, xdebug won't be able to connect to any IDE on your machine, even if the IDE says it is running the listener)
Hope this helps.
I get this message:
Status change detected: stopped
Error: Apache shutdown unexpectedly.
This may be due to a blocked port, missing dependencies,
improper privileges, a crash, or a shutdown by another method.
Press the Logs button to view error logs and check
the Windows Event Viewer for more clues
If you need more help, copy and post this
entire log window on the forums
all other services load, bar apache
this may happen often because of other programs using the port 80 or 443 which Apache uses.
I ran into this issue with Skype and I had to configure it to use another port rather than 443.
Check your port by typing in your command line netstat -np TCP | find "80" and for port 443 to see the network status of them.
Check your Skype configurations for the ports :
Tools->Options->Advanced->Connections and uncheck the button that says "Use port 80 and 443 ..."
I'm attempting to debug the startup of a service using the IFEO method (which I've successfully done on server versions prior to Windows 2012 on scenarios other than startup). The Debugger reg value is c:\debuggers-x64\cdb.exe -server tcp:port=1234. I then start the service and verify that cdb.exe is listening using netstat -na | findstr 1234 (I verified nothing was listening on this port prior to starting the service). Then I attempt to connect to the debugging server like this windbg.exe -remote tcp:server=localhost,port=1234 but it hangs for maybe 15-30 seconds and then fails. I try again and while it's hanging I run netstat -na | findstr 1234 again and it shows cdb.exe listening on port 1234 and it also shows a SYN_SENT to 127.0.0.1 on port 1234 (presumably sent by windbg.exe). It remains in the SYN_SENT state until windbg.exe reports a failure to connect.
So TCP connection establishment never completes. I checked the firewall and it's turned off. I also tried using the IP address of the network adapter (as opposed to localhost) but I get the same behavior. I also tried having cdb.exe listen on a port > 5000 but that also has the same behavior.
Does anyone know if there's new security introduced in Server 2012 for accessing TCP ports?
thanks