I want to remote debug the nodejs program in Eclipse. I start the node script with the debug option.
$node debug script.js
But I can't connect to the node in Eclispe. When I netstat the node's TCP port. I found that node only listen 127.0.0.1 in debug mode. So I can't connect it from different computer.
But I can't find any startup options that can change to listen to any address.
Anyone know to make it listen to any address to remote debug in other computer?
if anyone else stumble upon this: you can set the node debug to any address as you set the port
node --debug=169.168.1.2:5858 app.js
if that would be the ip of your remote machine or even better to every machine
node --debug=0.0.0.0:5858 app.js
but please be aware that the 2nd option should only be used if you are debugging in your own private network as you open it up for everyone
This is what I do in linux Debian:
install balancer
sudo apt-get install balance -y
then create a route in balancer to reroute your 5858 port to 5859
balance 5859 127.0.0.1:5858
start your app
node --debug app.js
now you can access it from everywhere on port 5859
I'm looking into V8 code that goes through deps/v8/src/debug-agent.* down to deps/v8/src/platform-posix.cpp (for linux) to POSIXSocket::Bind method and it can't seem to have any option about this (unless I'm missing something).
I bet you either hack it and recompile node or you'll need to build a small proxy beside your node process.
Here's a great tut on debugging nodejs from eclipse. Note at the bottom there is a script the author uses to forward localhost:5858 to the remote server's 127.0.0.1. You could also just use an SSH tunnel.
So, to summarize:
start your script with node --debug app.js
configure eclipse as if you were debugging locally
use the node_g script or configure an SSH tunnel
go on vacation now that your code is bug-free
to debug nodejs remotely over SSH session do:
1. install balance on Linux: https://balance.inlab.net/overview/
2. run the command: balance -df 8585 127.0.0.1:5858 > /tmp/balance.out 2>&1 &
3. ssh to your remote Linux box (tunnel will be created 8585 > 5858 > nodejs)
4. run your node script on server: node --debug-brk --nolazy ./myNodeApp.js
5. kick off debug session in WebStorm alt-d to port 8585
now you are remote debugging securely over SSH session
Related
How do i stop this?
Session stopped
- Press <return> to exit tab
- Press R to restart session
- Press S to save terminal output to file
Network error: Software caused connection abort
It looks SSH keepalive setting has no effect there
If you are still looking for the answer like me, here you go!
Settings -> Configuration -> SSH -> SSH keepalive
Restart MobaXTerm after changing the setting for it to take effect.
https://superuser.com/a/1298536
In my case I have SSH keepalive option checked but this happens every now and then.
So what I do is.
Disable (uncheck) SSH keeaplive close MobaXterm
Open MobaXterm and check SSH keeaplive close MobaXterm (again)
Open MobaXterm enjoy the stability for a couple of weeks...
I am using a licensed version on a computer running Windows 10 Professinal version 20H2.
Both solutions posted above (by #helloworld & #jepachecoh) actually work but there may be need for extra work, so here are a few additions.
The two options above work if:
1. You're connecting to a host (destination server) that is running SSH (daemon) but doesn't have any session timeout configurations set for connecting SSH clients.
2. You're connecting to a host that already has SSH client timeout configuration set but the set value (on the remote host) is either higher than, or equal to the "keepalive" value you have set on your SSH client (like MobaXterm, Putty etc).
If the destination server's "SSH keepalive configurations for the clients" are set, they override your remote client SSH keepalive configurations, hence controlling the session timeouts.
To find out if there are any configs set on the destination server's SSH configurations, use the command below (as root, or a user with sudo privileges):
$ cat /etc/ssh/sshd_config | grep "ClientAlive"
The command above works on multiple Linux and Solaris flavours.
If you don't have admin access to the destination server, your Systems administrator may be managing your session timeouts irrespective of the "keepalive" parameters you set on your SSH client before connecting.
Lastly, if you are using VPN software, or connecting to a demilitarized zone (DMZ), sometimes the session timeouts are controlled at that level (firewall level), so involve your Network administrator.
Bottom line, love your administrators. :-)
My Go application makes TLS connections via tls.Dial() to exchange data.
It works fine when run from the host:
But the outgoing connection doesn't seem to work when the app is run from a Docker container. The app hangs indefinitely.
Note 1: Same behavior with using docker run -p $(docker-machine ip):2500:2500 ...
Note 2: VM doesn't have extra port forwarding settings other than the default settings that came with docker-machine's default VM.
Docker image build with Dockerfile:
FROM golang:latest
RUN mkdir -p "$GOPATH/src/path/to/app"
# Install dependencies
RUN go get github.com/path/to/dep
VOLUME "$GOPATH/src/path/to/app"
EXPOSE 2500
WORKDIR "$GOPATH/src/path/to/app"
CMD ["go", "run", "main.go"]
Host is OS X running docker-machine.
Question
How can I make the TCP outgoing connection to work?
You are either using boot2docker or docker-machine (since you are running docker on OSX). If you are using boot2docker, you have to forward the ports on VirtualBox as well as docker, have a look at this blog post:
https://fogstack.wordpress.com/2014/02/09/docker-on-osx-port-forwarding/
If you are using docker-machine, you have to connect to the docker-machine assigned ip, not localhost, have a look at this post:
https://github.com/docker/machine/issues/710
I see now that you are using docker-machine specifically, so the post about docker-machine should answer your question.
Edit: I misunderstood the question. You are trying to make an outgoing connection on a forwarded port. That is not correct. By default docker can make outgoing connections on any port. The port forwarding is for incoming connections only. Please try again without specifying any ports to forward. My suspicion is that you are trying to make an outgoing connection on the incoming (forwarded) port.
I've just had exactly the same problem. Was unable to connect out at all.
Restarted the container, and suddenly outgoing connections worked fine. It's possible that the container survived an update of docker?
Currently using Docker version 18.09.3, build 774a1f4
I have a docker daemon/engine running inside guest (Ubuntu) virtual machine
and as per Docker Tooling for Eclipse instruction I had downloaded and setup the plugin in Eclipse Mars on my host Mac OS machine.
How do I connect to Docker running in guest VM from the host machine IDE.
As per instructions, I would need to enter TCP and authentication so how do I get these details to setup the connection?
I had tried with guest OS IP (i.e. tcp://127.0.0.1:2376 output of ifconfig command with local host IP) but was not able to connect.
Here are the steps I used to get Docker Tooling working in Eclipse Neon on Windows.
Open the Docker Quickstart Terminal
Execute docker-machine ls
Copy the URL (e.g. tcp://192.168.99.100:2376)
Click the Add Connection button in the toolbar for Docker Explorer
Provide a Connection name:
Select TCP Connection
Paste the above URL into the URI: edit box
Change tcp to https in the edit box
Select Enable authentication
Set the path to C:\Users\username\.docker\machine\certs
Click on Test Connection to verify
There are two parts to this. First, enabling the TCP socket (which I'll answer). Then, setting TLS authentication on the socket (which I'll link to but won't cover). The first part should get you up.
You'll need to edit the DOCKER_OPTS settings in /etc/default/docker in the VM. Edit this file and set DOCKER_OPTS to something like:
DOCKER_OPTS="-H tcp://0.0.0.0:2376 -H unix://"
Then, restart Docker (sudo service docker restart). This should get you a TCP connection that you can put in your Eclipse settings as:
tcp://10.0.2.15:2376
The second part (which is optional at this point) would be setting up the CA and certificates per https://docs.docker.com/engine/articles/https/. But I'd actually recommend just installing Docker Machine and provisioning your VM that way as it will create the needed certificates for you. Then, if your machine was named dev, you just point the authentication dir to ~/.docker/machine/machines/dev.
If Docker Daemon is running(i.e docker desktop running) in window task bar , not inside the VM , just get the URI from its context menu setting. In eclipse docker tooling perspective , we can connect to running docker daemon only by providing the URI.
I keep getting errors when trying to serve files locally. I am using Tomcat on port 8080.
When using Eclipse, I get the following error message:
Several ports (8080, 8009) required by Tomcat v8.0 Server at localhost are already in use. The server may already be running in another process, or a system process may be using the port. To start this server you will need to stop the other process or change the port number(s).
Question
How do I stop the server on port 8080 if I don't know which process started it?
Try to go with a web browser to:
localhost:8080 or 127.0.0.1:8080
and
localhost:8009 or 127.0.0.1:8009
There you could see which service is running on those ports.
Then it will be more simple to understand what you have to stop.
EDIT:
You could use a prompt and the command:
netstat -b
-b it will show the name of the executable running on a port.
For understanding how it works here a good explanation.
When veewee is displaying the following message, Waiting for ssh login on 127.0.0.1 with user veewee to sshd on port => 7222 to work, timeout=10000 sec what exactly is it waiting on?
As far as I can tell there is a ssh server on port 7222 on the host that veewee has put up and it's waiting on that. This means that something in the guest is going to connect back to it. However, I can't figure out what that thing might be - and thus I can't debug further.
Further details
I'm trying to build a virtualbox image for vagrant with the CentOS-6.3-x86_64-minimal template. My steps:
bundle exec veewee vbox define 'ejs-centos6.3-1' 'CentOS-6.3-x86_64-minimal'
wget http://mirror.symnds.com/distributions/CentOS-vault/6.3/isos/x86_64/CentOS-6.3-x86_64-minimal.iso
bundle exec veewee vbox build 'ejs-centos6.3-1'
The CentOS install appeared to run without error but it's stuck waiting for the ssh login.
You're right, there's a Ssh server on listening on port 7222, but it's on the guest (VM), not the host.
The host (Veewee) is waiting to connect to it. This SSH service is supposed to become available when the VM install process finishes, that's one of the steps used by Veewee to assume that the setup went fine and that the VM is ready.
If Veewee blocks and never gets this SSH connection, I think there could be multiple reasons:
VM setup went wrong and something prevents it from finishing successfully. Check Veewee output and the Virtualbox VM graphical console that should have opened when launching vewee box build.
There's something preventing your host computer to connect to the VM at the network level.
The VM image doesn't have Sshd installed, and/or the veewee box configuration files (in veewee/definitions/ejs-centos6.3-1/) miss instructions to install the ssh package
You should try to login to the VM using Virtuabox console window and check if there's an ssh package installed (rpm -qa | grep openssh-server) and a process named sshd running.
I've run Veewee against Centos 7 built with GUI on and it stuck on anaconda asking for source of packages. I've checked the ks.cfg and it was pointing to dead resource (404). After pointing to valid url it went through.