I just set up my first Amazon AWS server, with a Node.js installation on it. I run my app, at which point Node says that it's listening on port 3000. However, if I close my laptop, Node.js is no longer reachable through my app. How can I make it run even when I'm not logged in to the server through Putty? As a follow-up question, how can I re-open the Node instance (so that I see the any console.log messages from it) when I log back in to my server?
Thank you!
This is part StackOverflow, part Serverfault question I believe. It sounds like the problem is you're running the node server in the foreground of your SSH session, but you'd rather run it like a service (in the background).
When you exec something like that simple node server, you're running it (by default) in your SSH connection, which ends when your connection terminates from sleeping your computer. Some scripts/programs will run by default in the background, but if you're seeing results in STDOUT (printing to the shell) it is running in the foreground.
Highjacking these answers: Node.js as a background service
Two solutions
*nix solution: http://en.wikipedia.org/wiki/Nohup
Node solution: https://github.com/nodejitsu/forever
Related
I'm trying to debug on a live server running a Node.js webserver (Express, TypeScript).
I run the node server with NODE_ENV=development node --inspect=9229 --inspect-brk build/start.js, and it says it's waiting and listening (Debugger listening on ws://127.0.0.1:9229/a61485f2-aef8-4719-901d-4d5ad9d1e6cd).
I set up an SSH tunnel (using this method: https://gist.github.com/pajtai/081e0371e7366c79c0b9), and I set up an "Attach to Node.js/Chrome" debug configuration, with Host: localhost and Port: 9229. Then when I hit the debug button, it connects through the SSH tunnel, and the node.js process runs just fine, stopping and debugging at all my breakpoints.
However, when I don't set up the SSH tunnel, start the node server the same way, and set up an "Attach to Node.js/Chrome" profile with the host as the URL or IP of the server, WebStorm can never connect. There is a little red bubble over the "5: Debug" icon at the bottom saying it can't connect, and sometimes it says "Closed Explicitly". I have opened up port 9229 in the firewall settings for the server (I've tried TCP and UDP).
What am I doing wrong? Please help, anyone!
I'm using Mac OS X 10.15.3 and WebStorm 2019.3.1.
Node binds to localhost by default and thus can't be accessed from outside unless you set up the port forwarding (via ssh tunneling, for example).
You can try changing the command to node --inspect-brk=0.0.0.0:9229 build/start.js - does it help?
Note that Node.js discourages using remote debugging in this way: https://nodejs.org/en/docs/guides/debugging-getting-started/#enabling-remote-debugging-scenarios. Using SSH tunneling is recommended
Cloudflare Argo Tunnel from Node child_process
I have an electron app from which I would like to spawn a child process that executes
cloudflared tunnel --url localhost:3000
inside a certain directory. Executing this from cmd inside that directory instantiates the argo tunnel as expected, and the url works while the process is running. This is how I am executing the command from the electron app:
const { spawn } = require('child_process')
let tunnel = spawn('cloudflared', ['tunnel', '--url', 'localhost:4000'], {
stdio: 'inherit', // Will use process .stdout, .stdin, .stderr
cwd: 'c://cloudflare'
})
I can see the normal console output from cloudflare indicating that the tunnel has been established and my server is responding at some-random-name.trycloudflare.com. However, when the process is started from within the electron app, I get Error 1016 displayed on a cloudflare error page.
Does anyone have experience with Argo Tunnel and child_process?
I was able to get your setup to work on my Mac without issue, so you need to look further into the details of your setup. Here is what I did:
Installed Electron Fiddle v0.9.0 from GitHub
Installed cloudflared version 2019.8.4 via homebrew with
brew install cloudflare/cloudflare/cloudflared
From the command line (Terminal window), ran
cloudflared tunnel --url localhost:3000
cloudflared had some complaints:
Cannot determine default configuration path. No file [config.yml config.yaml] in [~/.cloudflared ~/.cloudflare-warp ~/cloudflare-warp /usr/local/etc/cloudflared /etc/cloudflared]
cloudflared will not automatically update when run from the shell
unable to connect to the origin error="Get http://localhost:3000: dial tcp [::1]:3000: connect: connection refused"
Started a web server on localhost:3000 with
python -m SimpleHTTPServer 3000
Loaded the page http://localhost:3000 in my browser
Again ran
cloudflared tunnel --url localhost:3000
Same complaints, except this time it was able to connect:
Proxying tunnel requests to http://localhost:3000
Further output from cloudflared indicated it was bringing up 4 tunnels. For each tunnel, it output
+-----------------------------------------------------------+
| Your free tunnel has started! Visit it: |
| https://sides-universe-gym-metadata.trycloudflare.com |
+-----------------------------------------------------------+
Route propagating, it may take up to 1 minute for your new route to become functional
Note that I did not change or obfuscate the URL, that is exactly what was output, and cloudflared output the same URL 4 times, once for each tunnel.
I went to https://sides-universe-gym-metadata.trycloudflare.com and verified it displayed the same website I had brought up on localhost:3000.
I quit cloudflared by typing ctrl-c in the Terminal window where it was running. It took quite some time to shut down, but I waited until it quit.
I went to https://sides-universe-gym-metadata.trycloudflare.com and verified it displayed an error. It displayed "Error 1016" and "Origin DNS error".
In Electron Fiddle, I selected Electron v6.0.6 and used the default, pre-installed main.js, index.html, and renderer.js. In main.js, I added at the bottom
const { spawn } = require('child_process')
let tunnel = spawn('cloudflared', ['tunnel', '--url', 'localhost:3000'], {
stdio: 'inherit', // Will use process .stdout, .stdin, .stderr
cwd: '/Users/user/development'
})
I clicked "Run" on Electron Fiddle. The "Hello World!" page came up. The Electron Console showed output from cloudflared.
Again cloudflared brought up 4 tunnels, each with the URL https://citysearch-celebs-generator-history.trycloudflare.com
cloudflared then logged:
cloudflared has been updated to version 2019.8.4
PID of the new process is 81076
Quitting...
Metrics server stopped
I have no idea why it "updated" from "2019.8.4" to "2019.8.4". Maybe it has something to do with not having a default configuration, maybe it had something to do with Electron Fiddle running it from a non-standard location. I suspect it is because the command line did not include --is-autoupdated=true.
Immediately after "Metrics server stopped" cloudflared started logging its startup messages, just as before.
Again it brought up 4 tunnels, this time with URL https://gifts-jpg-treasury-correct.trycloudflare.com
Total time elapsed from start through restart to last stable tunnel up: 14 seconds.
I went to https://gifts-jpg-treasury-correct.trycloudflare.com in my local browser and again got the site I was hosting at localhost:3000.
I hit "Stop" in Electron. The Electron server stopped, but cloudflared kept running. I could still load https://gifts-jpg-treasury-correct.trycloudflare.com/
I hit "Run" in Electron. Again cloudflared brought up 4 tunnels. This time it did not auto-update or restart. The 4 new tunnels all had the same new URL: https://reject-pride-built-twisted.trycloudflare.com/
I went to https://reject-pride-built-twisted.trycloudflare.com/ in my local browser and again got the site I was hosting at localhost:3000. I tried https://gifts-jpg-treasury-correct.trycloudflare.com and it, too, was still working.
So I cannot reproduce your problem. Possible issues are that you may have been looking at the first tunnel that came up but cloudflared had updated, closed that tunnel, and started a different one. This worked for me on Mac but it seems you are working on Windows so it could be some Windows-specific issue. It could be that you do not have a server running on localhost:4000 or that your Electron app cannot access C://clouflare.
You need to provide more information, such as the log output of your Electron app running cloudflared and details about the server running at localhost:4000 and any cloudflared configuration files you have set up.
Common cause
Cloudflare cannot resolve the origin web server’s IP address.
Common causes for Error 1016 are:
A missing DNS A record that mentions the origin IP address.
A CNAME record in Cloudflare DNS points to an unresolvable external domain.
The origin host names (CNAMEs) in your Cloudflare Load Balancer default, region, and fallback pools are unresolvable. Use a fallback pool configured with an origin IP as a backup in case all other pools are unavailable.
Resolution
To resolve error 1016:
1) Verify your Cloudflare DNS settings include an A record that points to a valid IP address that resolves via a DNS lookup tool.
2) For a CNAME record pointing to a different domain, ensure that the target domain resolves via a DNS lookup tool.
I have a node server with several node projects. I use nginx to get them all responding on port 80. Now, this works for the initial http request. For the websockets, I need to use the direct server port. To keep everything alive while developing I would like to try this, projects will have a dev and live version. Once de dev is stable, I will copy it to the live folder. The live folder is runned by a systemctl script where I define a difrent port to the live version so I can dev without taking the live down. The problem I encounter now is, how can I get the running server port in my client side Javascript so that the dev page connect to the dev port and visa versa?
currently I'm only using express, socket.io and mysql. I have no further npm packages installed. I searched allot but there is not to mush I can find. I found how to connect the socket to the page url but I cannot use that because that URL will always be on port 80. Further I found allot of huge packages that has no use for me since the original page is just static, the dynamics all run over websockets.
Is there any way to parse the port number in the clients .js file like I could do fairly easy in php? And if so, what would be the most efficient way. I could let javascript check if the page uses the live or dev URL but I would prefer not to hardcode my dev URL into JS where it is for everyone to see.
run a third node.js socket.io server program, all your clients connect to this server first.
In this simple node.js program, determine the type of clients by any means. e.g. different user id for dev/production users
send the server url and port to your client according to its type (dev or production)
you may also use this technique to separate your users to different production servers.
I have an MEAN application running on server through Amazon Lightsail. I installed my application in the /projects folder and once I ssh onto the server and run node bin/www (where my main startup scripts live) the site runs perfectly. The issue comes once I close the ssh shell the site goes down (node stops running). Does lightsail / AWS provide any utilities to keep up the server or do I need to manually install a service that keeps it up so I can point a domain at the IP and it is consistently running?
I have successfully installed Node.JS and Balloons.IO chatroom on my linux based vps (with SSH). When typing curl http://mydomain.com:9191/ in the ssh command I can see the html is loaded. But, when trying to reach the same page from my browser it takes some time loading then says page could not be reached. Any idea why ?
My common diagnostic steps:
1) Check that your app is actually listening on the port it should be, you can do this with:
sudo netstat -anp | grep :9191
You should see your app listening to 0.0.0.0:9191 or your.ip.address.here:9191 if you see something like 127.0.0.1:9191, then it is only listening locally so you won't be able to reach it.
2) Ensure your firewall isn't blocking these ports, if you are using iptables you can check with:
sudo iptables --list
This will print the rules for your firewall and you can check if you port is blocked (or allowed).
3) Try connecting locally. My third step is generally to try it locally with curl, you did this step already but for other landing here you can do something like:
curl http://localhost:9191/
and see what you get back
4) Try connecting remotely. If everything above looks fine, try running a verbose curl from a remote host and see what you get:
curl -v http://mydomain.com:9191/
This will show header and body output so you can see if the remote host even responds; if it doesn't then check if the raw port is even accessable with telnet:
telnet mydomain.com 9191
which if successful will print something like:
Trying your.ip.address.here...
Connected to mydomain.com.
Escape character is '^]'.
If it fails it will just hang at Trying... if it fails then your firewall is blocking the port, your host is blocking the port, or your app isn't listening to the port. If your above tests passed then contact your host because something else may be up and you should be able to get support from them.