Since this post has gotten a lot of attention over the years, I've listed the top solutions per platform at the bottom of this post.
Original post:
I want my node.js server to run in the background, i.e.: when I close my terminal I want my server to keep running. I've googled this and came up with this tutorial, however it doesn't work as intended. So instead of using that daemon script, I thought I just used the output redirection (the 2>&1 >> file part), but this too does not exit - I get a blank line in my terminal, like it's waiting for output/errors.
I've also tried to put the process in the background, but as soon as I close my terminal the process is killed as well.
So how can I leave it running when I shut down my local computer?
Top solutions:
Systemd (Linux)
Launchd (Mac)
node-windows (Windows)
PM2 (Node.js)
Copying my own answer from How do I run a Node.js application as its own process?
2015 answer: nearly every Linux distro comes with systemd, which means forever, monit, PM2, etc are no longer necessary - your OS already handles these tasks.
Make a myapp.service file (replacing 'myapp' with your app's name, obviously):
[Unit]
Description=My app
[Service]
ExecStart=/var/www/myapp/app.js
Restart=always
User=nobody
# Note Debian/Ubuntu uses 'nogroup', RHEL/Fedora uses 'nobody'
Group=nogroup
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/var/www/myapp
[Install]
WantedBy=multi-user.target
Note if you're new to Unix: /var/www/myapp/app.js should have #!/usr/bin/env node on the very first line and have the executable mode turned on chmod +x app.js.
Copy your service file into the /etc/systemd/system.
Start it with systemctl start myapp.
Enable it to run on boot with systemctl enable myapp.
See logs with journalctl -u myapp
This is taken from How we deploy node apps on Linux, 2018 edition, which also includes commands to generate an AWS/DigitalOcean/Azure CloudConfig to build Linux/node servers (including the .service file).
You can use Forever, A simple CLI tool for ensuring that a given node script runs continuously (i.e. forever):
https://www.npmjs.org/package/forever
UPDATE - As mentioned in one of the answers below, PM2 has some really nice functionality missing from forever. Consider using it.
Original Answer
Use nohup:
nohup node server.js &
EDIT I wanted to add that the accepted answer is really the way to go. I'm using forever on instances that need to stay up. I like to do npm install -g forever so it's in the node path and then just do forever start server.js
This might not be the accepted way, but I do it with screen, especially while in development because I can bring it back up and fool with it if necessary.
screen
node myserver.js
>>CTRL-A then hit D
The screen will detach and survive you logging off. Then you can get it back back doing screen -r. Hit up the screen manual for more details. You can name the screens and whatnot if you like.
2016 Update:
The node-windows/mac/linux series uses a common API across all operating systems, so it is absolutely a relevant solution. However; node-linux generates systemv init files. As systemd continues to grow in popularity, it is realistically a better option on Linux. PR's welcome if anyone wants to add systemd support to node-linux :-)
Original Thread:
This is a pretty old thread now, but node-windows provides another way to create background services on Windows. It is loosely based on the nssm concept of using an exe wrapper around your node script. However; it uses winsw.exe instead and provides a configurable node wrapper for more granular control over how the process starts/stops on failures. These processes are available like any other service:
The module also bakes in some event logging:
Daemonizing your script is accomplished through code. For example:
var Service = require('node-windows').Service;
// Create a new service object
var svc = new Service({
name:'Hello World',
description: 'The nodejs.org example web server.',
script: 'C:\\path\\to\\my\\node\\script.js'
});
// Listen for the "install" event, which indicates the
// process is available as a service.
svc.on('install',function(){
svc.start();
});
// Listen for the "start" event and let us know when the
// process has actually started working.
svc.on('start',function(){
console.log(svc.name+' started!\nVisit http://127.0.0.1:3000 to see it in action.');
});
// Install the script as a service.
svc.install();
The module supports things like capping restarts (so bad scripts don't hose your server) and growing time intervals between restarts.
Since node-windows services run like any other, it is possible to manage/monitor the service with whatever software you already use.
Finally, there are no make dependencies. In other words, a straightforward npm install -g node-windows will work. You don't need Visual Studio, .NET, or node-gyp magic to install this. Also, it's MIT and BSD licensed.
In full disclosure, I'm the author of this module. It was designed to relieve the exact pain the OP experienced, but with tighter integration into the functionality the Operating System already provides. I hope future viewers with this same question find it useful.
If you simply want to run the script uninterrupted until it completes you can use nohup as already mentioned in the answers here. However, none of the answers provide a full command that also logs stdin and stdout.
nohup node index.js >> app.log 2>&1 &
The >> means append to app.log.
2>&1 makes sure that errors are also send to stdout and added to the app.log.
The ending & makes sure your current terminal is disconnected from command so you can continue working.
If you want to run a node server (or something that should start back up when the server restarts) you should use systemd / systemctl.
UPDATE: i updated to include the latest from pm2:
for many use cases, using a systemd service is the simplest and most appropriate way to manage a node process. for those that are running numerous node processes or independently-running node microservices in a single environment, pm2 is a more full featured tool.
https://github.com/unitech/pm2
http://pm2.io
it has a really useful monitoring feature -> pretty 'gui' for command line monitoring of multiple processes with pm2 monit or process list with pm2 list
organized Log management -> pm2 logs
other stuff:
Behavior configuration
Source map support
PaaS Compatible
Watch & Reload
Module System
Max memory reload
Cluster Mode
Hot reload
Development workflow
Startup Scripts
Auto completion
Deployment workflow
Keymetrics monitoring
API
Try to run this command if you are using nohup -
nohup npm start 2>/dev/null 1>/dev/null&
You can also use forever to start server
forever start -c "npm start" ./
PM2 also supports npm start
pm2 start npm -- start
If you are running OSX, then the easiest way to produce a true system process is to use launchd to launch it.
Build a plist like this, and put it into the /Library/LaunchDaemons with the name top-level-domain.your-domain.application.plist (you need to be root when placing it):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>top-level-domain.your-domain.application</string>
<key>WorkingDirectory</key>
<string>/your/preferred/workingdirectory</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/node</string>
<string>your-script-file</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
When done, issue this (as root):
launchctl load /Library/LaunchDaemons/top-level-domain.your-domain.application.plist
launchctl start top-level-domain.your-domain.application
and you are running.
And you will still be running after a restart.
For other options in the plist look at the man page here: https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man5/launchd.plist.5.html
I am simply using the daemon npm module:
var daemon = require('daemon');
daemon.daemonize({
stdout: './log.log'
, stderr: './log.error.log'
}
, './node.pid'
, function (err, pid) {
if (err) {
console.log('Error starting daemon: \n', err);
return process.exit(-1);
}
console.log('Daemonized successfully with pid: ' + pid);
// Your Application Code goes here
});
Lately I'm also using mon(1) from TJ Holowaychuk to start and manage simple node apps.
I use Supervisor for development. It just works. When ever you make changes to a .js file Supervisor automatically restarts your app with those changes loaded.
Here's a link to its Github page
Install :
sudo npm install supervisor -g
You can easily make it watch other extensions with -e. Another command I use often is -i to ignore certain folders.
You can use nohup and supervisor to make your node app run in the background even after you log out.
sudo nohup supervisor myapp.js &
Node.js as a background service in WINDOWS XP
Kudos goes to Hacksparrow at: http://www.hacksparrow.com/install-node-js-and-npm-on-windows.html for tutorial installing Node.js + npm for windows.
Kudos goes to Tatham Oddie at: http://blog.tatham.oddie.com.au/2011/03/16/node-js-on-windows/ for nnsm.exe implementation.
Installation:
Install WGET http://gnuwin32.sourceforge.net/packages/wget.htm via installer executable
Install GIT http://code.google.com/p/msysgit/downloads/list via installer executable
Install NSSM http://nssm.cc/download/?page=download via copying nnsm.exe into %windir%/system32 folder
Create c:\node\helloworld.js
// http://howtonode.org/hello-node
var http = require('http');
var server = http.createServer(function (request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end("Hello World\n");
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
Open command console and type the following (setx only if Resource Kit is installed)
C:\node> set path=%PATH%;%CD%
C:\node> setx path "%PATH%"
C:\node> set NODE_PATH="C:\Program Files\nodejs\node_modules"
C:\node> git config --system http.sslcainfo /bin/curl-ca-bundle.crt
C:\node> git clone --recursive git://github.com/isaacs/npm.git
C:\node> cd npm
C:\node\npm> node cli.js install npm -gf
C:\node> cd ..
C:\node> nssm.exe install node-helloworld "C:\Program Files\nodejs\node.exe" c:\node\helloworld.js
C:\node> net start node-helloworld
A nifty batch goodie is to create c:\node\ServiceMe.cmd
#echo off
nssm.exe install node-%~n1 "C:\Program Files\nodejs\node.exe" %~s1
net start node-%~n1
pause
Service Management:
The services themselves are now accessible via Start-> Run->
services.msc or via Start->Run-> MSCONFIG-> Services (and check 'Hide
All Microsoft Services').
The script will prefix every node made via the batch script with
'node-'.
Likewise they can be found in the registry: "HKLM\SYSTEM\CurrentControlSet\Services\node-xxxx"
The accepted answer is probably the best production answer, but for a quick hack doing dev work, I found this:
nodejs scriptname.js & didn't work, because nodejs seemed to gobble up the &, and so the thing didn't let me keep using the terminal without scriptname.js dying.
But I put nodejs scriptname.js in a .sh file, and
nohup sh startscriptname.sh & worked.
Definitely not a production thing, but it solves the "I need to keep using my terminal and don't want to start 5 different terminals" problem.
June 2017 Update:
Solution for Linux: (Red hat). Previous comments doesn't work for me.
This works for me on Amazon Web Service - Red Hat 7. Hope this works for somebody out there.
A. Create the service file
sudo vi /etc/systemd/system/myapp.service
[Unit]
Description=Your app
After=network.target
[Service]
ExecStart=/home/ec2-user/meantodos/start.sh
WorkingDirectory=/home/ec2-user/meantodos/
[Install]
WantedBy=multi-user.target
B. Create a shell file
/home/ec2-root/meantodos/start.sh
#!/bin/sh -
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to 8080
npm start
then:
chmod +rx /home/ec2-root/meantodos/start.sh
(to make this file executable)
C. Execute the Following
sudo systemctl daemon-reload
sudo systemctl start myapp
sudo systemctl status myapp
(If there are no errors, execute below. Autorun after server restarted.)
chkconfig myapp -add
If you are running nodejs in linux server, I think this is the best way.
Create a service script and copy to /etc/init/nodejs.conf
start service: sudo service nodejs start
stop service: sudo service nodejs stop
Sevice script
description "DManager node.js server - Last Update: 2012-08-06"
author "Pedro Muniz - pedro.muniz#geeklab.com.br"
env USER="nodejs" #you have to create this user
env APPNAME="nodejs" #you can change the service name
env WORKDIR="/home/<project-home-dir>" #set your project home folder here
env COMMAND="/usr/bin/node <server name>" #app.js ?
# used to be: start on startup
# until we found some mounts weren't ready yet while booting:
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
pre-start script
sudo -u $USER echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/$APPNAME.log
end script
script
# Not sure why $HOME is needed, but we found that it is:
export HOME="<project-home-dir>" #set your project home folder here
export NODE_PATH="<project node_path>"
#log file, grant permission to nodejs user
exec start-stop-daemon --start --make-pidfile --pidfile /var/run/$APPNAME.pid --chuid $USER --chdir $WORKDIR --exec $COMMAND >> /var/log/$APPNAME.log 2>&1
end script
post-start script
# Optionally put a script here that will notifiy you node has (re)started
# /root/bin/hoptoad.sh "node.js has started!"
end script
pre-stop script
sudo -u $USER echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/$APPNAME.log
end script
use nssm the best solution for windows, just download nssm, open cmd to nssm directory and type
nssm install <service name> <node path> <app.js path>
eg: nssm install myservice "C:\Program Files\nodejs" "C:\myapp\app.js"
this will install a new windows service which will be listed at services.msc from there you can start or stop the service, this service will auto start and you can configure to restart if it fails.
Use pm2 module. pm2 nodejs module
Since I'm missing this option in the list of provided answers I'd like to add an eligible option as of 2020: docker or any equivalent container platform. In addition to ensuring your application is working in a stable environment there are additional security benefits as well as improved portability.
There is docker support for Windows, macOS and most/major Linux distributions. Installing docker on a supported platform is rather straight-forward and well-documented. Setting up a Node.js application is as simple as putting it in a container and running that container while making sure its being restarted after shutdown.
Create Container Image
Assuming your application is available in /home/me/my-app on that server, create a text file Dockerfile in folder /home/me with content similar to this one:
FROM node:lts-alpine
COPY /my-app/ /app/
RUN cd /app && npm ci
CMD ["/app/server.js"]
It is creating an image for running LTS version of Node.js under Alpine Linux, copying the application's files into the image and runs npm ci to make sure dependencies are matching that runtime context.
Create another file .dockerignore in same folder with content
**/node_modules
This will prevent existing dependencies of your host system from being injected into container as they might not work there. The presented RUN command in Dockerfile is going to fix that.
Create the image using command like this:
docker build -t myapp-as-a-service /home/me
The -t option is selecting the "name" of built container image. This is used on running containers below.
Note: Last parameter is selecting folder containing that Dockerfile instead of the Dockerfile itself. You may pick a different one using option -f.
Start Container
Use this command for starting the container:
docker run -d --restart always -p 80:3000 myapp-as-a-service
This command is assuming your app is listening on port 3000 and you want it to be exposed on port 80 of your host.
This is a very limited example for sure, but it's a good starting point.
To round out the various options suggested, here is one more: the daemon command in GNU/Linux, which you can read about here: http://libslack.org/daemon/manpages/daemon.1.html. (apologies if this is already mentioned in one of the comments above).
Check out fugue! Apart from launching many workers, you can demonize your node process too!
http://github.com/pgte/fugue
PM2 is a production process manager for Node.js applications with a built-in load balancer. It allows you to keep applications alive forever, to reload them without downtime and to facilitate common system admin tasks.
https://github.com/Unitech/pm2
I am surprised that nobody has mentioned Guvnor
I have tried forever, pm2, etc. But, when it comes to solid control and web based performance metrics, I have found Guvnor to be by far the best. Plus, it is also fully opensource.
Edit : However, I am not sure if it works on windows. I've only used it on linux.
has anyone noticed a trivial mistaken of the position of "2>&1" ?
2>&1 >> file
should be
>> file 2>&1
I use tmux for a multiple window/pane development environment on remote hosts. It's really simple to detach and keep the process running in the background. Have a look at tmux
For people using newer versions of the daemon npm module - you need to pass file descriptors instead of strings:
var fs = require('fs');
var stdoutFd = fs.openSync('output.log', 'a');
var stderrFd = fs.openSync('errors.log', 'a');
require('daemon')({
stdout: stdoutFd,
stderr: stderrFd
});
If you are using pm2, you can use it with autorestart set to false:
$ pm2 ecosystem
This will generate a sample ecosystem.config.js:
module.exports = {
apps: [
{
script: './scripts/companies.js',
autorestart: false,
},
{
script: './scripts/domains.js',
autorestart: false,
},
{
script: './scripts/technologies.js',
autorestart: false,
},
],
}
$ pm2 start ecosystem.config.js
I received the following error when using #mikemaccana's accepted answer on a RHEL 8 AWS EC2 instance: (code=exited, status=216/GROUP)
It was due to using the user/group set to: 'nobody'.
Upon googling, it seems that using user/group as 'nobody'/'nogroup' is bad practice for daemons as answered here on the unix stack exchange.
It worked great after I set user/group to my actual user and group.
You can enter whomai and groups to see your available options to fix this.
My service file for a full stack node app with mongodb:
[Unit]
Description=myapp
After=mongod.service
[Service]
ExecStart=/home/myusername/apps/myapp/root/build/server/index.js
Restart=always
RestartSec=30
User=myusername
Group=myusername
Environment=PATH=/usr/bin:/usr/local/bin
Environment=NODE_ENV=production
WorkingDirectory=/home/myusername/apps/myapp
[Install]
WantedBy=multi-user.target
In case, for local development purpose, you need to start multiple instances of NodeJS app (express, fastify, etc.) then the concurrently might be an option. Here is a setup:
Prerequesites
Your NodeJS app (express, fastify, etc.) is placed at /opt/mca/www/mca-backend/app path.
Assuming that you are using node v.16 installed via brew install node#16
Setup
Install concurrently: npm install -g concurrently
Create a file ~/Library/LaunchAgents/mca.backend.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>mca.backend</string>
<key>LimitLoadToSessionType</key>
<array>
<string>Aqua</string>
<string>Background</string>
<string>LoginWindow</string>
<string>StandardIO</string>
<string>System</string>
</array>
<key>ProgramArguments</key>
<array>
<string>/usr/local/bin/concurrently</string>
<string>--names</string>
<string>dev,prd</string>
<string>--success</string>
<string>all</string>
<string>--kill-others</string>
<string>--no-color</string>
<string>MCA_APP_STAGE=dev node ./server.mjs</string>
<string>MCA_APP_STAGE=prod node ./server.mjs</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>EnvironmentVariables</key>
<dict>
<key>PATH</key>
<string>/usr/local/opt/node#16/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin</string>
</dict>
<key>WorkingDirectory</key>
<string>/opt/mca/www/mca-backend/app</string>
<key>StandardErrorPath</key>
<string>/opt/mca/www/mca-backend/err.log</string>
<key>StandardOutPath</key>
<string>/opt/mca/www/mca-backend/out.log</string>
</dict>
</plist>
Load and run: launchctl bootstrap gui/`id -u` $HOME/Library/LaunchAgents/mca.backend.plist
Get a status: launchctl print gui/`id -u`/mca.backend
Stop: launchctl kill SIGTERM gui/`id -u`/mca.backend
Start/Restart: launchctl kickstart -k -p gui/`id -u`/mca.backend
Unload if not needed anymore: launchctl bootout gui/`id -u`/mca.backend
IMPORTANT: Once you are loaded service with launchctl bootstrap any changes you made in file
~/Library/LaunchAgents/mca.backend.plist won't be in action until you unload the service (by using launchctl bootout)
and then load it again (by using launchctl bootstrap).
Troubleshooting
See launchd logs at: /private/var/log/com.apple.xpc.launchd/launchd.log
This answer is quite late to the party, but I found that the best solution was to write a shell script that used the both the screen -dmS and nohup commands.
screen -dmS newScreenName nohup node myserver.js >> logfile.log
I also add the >> logfile bit on the end so I can easily save the node console.log() statements.
Why did I use a shell script? Well I also added in an if statement that checked to see if the node myserver.js process was already running.
That way I was able to create a single command line option that both lets me keep the server going and also restart it when I have made changes, which is very helpful for development.
I want to run a node application from my raspberry pi. The application is supposed to start on boot.
I have included the following lines in /etc/rc.local (before exit 0) :
cd /home/pi/PPBot
node bot.js > dev/null &
I first navigate to the correct folder and then run the bot from there. However the node application is not running when I reboot my raspberry pi. So it seems that rc.local is not executed or unable to execute the lines I provided.
I am looking for a solution so that the application will run at boot.
save this
[Unit]
Description=Node JS Script Service
After=network.target
[Service]
Type=simple
ExecStart=/usr/bin/node /path/to/hello_env.js
Restart=on-failure
[Install]
WantedBy=multi-user.target
to /etc/systemd/system/ as nodescript.service
sudo systemctl daemon-reload
sudo systemctl start nodescript
if it worked, make it startup on boot
sudo systemctl enable nodescript
The examples I 've seen (like this one) used
cd /home/pi/PPBot
node bot.js < dev/null &
instead of
cd /home/pi/PPBot
node bot.js > dev/null &
Note the < instead of the >. As you can see here, the < redirects the Standard In (stdin), while the > redirects the Standard Output (stdout). And as described here,
< /dev/null is used to instantly send EOF to the program, so that it doesn't wait for input (/dev/null, the null device, is a special file that discards all data written to it, but reports that the write operation succeeded, and provides no data to any process that reads from it, yielding EOF immediately). & is a special type of command separator used to background the preceding process.
Since you havent used < dev/null, maybe your program is stuck and waits for some input. The & at the end makes your program run in the background. Try to not include it and see if your Rasberry Pi is still booting. If not, you know that your programs runs continously and blocks further booting; when you used the & sign, your program just failed in a separate process. In this case changing the > to < should help because your programs doesn't wait for input.
If the above doesn't work, update your question with the specific error message. You can view the boot log by using the command dmesg (display message).
In this case when you
cd /home/pi/PPBot
you are no longer in the root directory so when you run
node bot.js > dev/null &
it is looking for the dev folder at /home/pi/PPBot/dev
You will need to add a leading / to ensure it is accessing /dev
change
node bot.js > dev/null &
to
node bot.js > /dev/null &
When I start my server with node app.js in the command line (using Git Bash), I can stop it using ctrl + C.
In my package.json file i got this start-script that allows me to use the command npm start to start the server:
"scripts": {
"start": "node app"
},
When I do this, the server starts as normal:
$ npm start
> nodekb#1.0.0 start C:\Projects\nodekb
> node app.js
Server started on port 3000...
But when i ctrl + C now, the server does not get stopped (the node process still remains in task manager). This means that I get an error when I try to do npm start again, because port 3000 is still being used.
I'm following a tutorial on youtube (video with timestamp), and when this guy ctrl + C and then runs npm start again, it works as normal.
Any ideas why my server process is not stopped when I use ctrl + C?
My app.js file if needed:
var express = require("express");
var path = require("path");
//Init app
var app = express();
//Load View Engine
app.set("views", path.join(__dirname, "views"));
app.set("view engine", "pug");
//Home Route
app.get("/", function(req, res) {
res.render("index", {
title: "Hello"
});
});
//Add route
app.get("/articles/add", function (req, res) {
res.render("add_article", {
title: "Add Article"
});
});
//Start server
app.listen(3000, function() {
console.log("Server started on port 3000...");
});
Thanks!
Ctrl + C does not kill the server. The resolution to the issue was using following code snippet in server.js:
process.on('SIGINT', function() {
console.log( "\nGracefully shutting down from SIGINT (Ctrl-C)" );
// some other closing procedures go here
process.exit(0);
});
This worked for me.
You can also check for other solutions mentioned at Graceful shutdown in NodeJS
I tried it on normal windows cmd, and it worked as it should there. Looks like it's a problem with git bash.
I encountered this problem in MSYS2 proper, even in latest build (x64 2018-05-31).
Luckily, Git for Windows maintain a customized MSYS2 runtime. They have patches that have not been sent upstream, including a patch that fixes emulation of SIGINT, SIGTERM and SIGKILL.
Discussion: https://github.com/nodejs/node/issues/16103
I was able to make my "MSYS2 proper" platform use Git for Windows' MSYS2 runtime, by following these instructions.
Repeated here for posterity:
Install inside MSYS2 proper
This guide assumes that you want the 64-bit version of Git for Windows.
Git for Windows being based on MSYS2, it's possible to install the git package into an existing MSYS2 installation. That means that if you are already using MSYS2 on your computer, you can use Git for Windows without running the full installer or using the portable version.
Note however that there are some caveats for going this way. Git for Windows created some patches for msys2-runtime that have not been sent upstream. (This had been planned, but it was determined in issue #284 that it would probably not be happening.) This means that you have to install Git for Windows customized msys2-runtime to have a fully working git inside MSYS2.
Here the steps to take:
Open an MSYS2 terminal.
Edit /etc/pacman.conf and just before [mingw32] (line #71 on my machine), add the git-for-windows packages repository:
[git-for-windows]
Server = https://wingit.blob.core.windows.net/x86-64
and optionally also the MINGW-only repository for the opposite architecture (i.e. MINGW32 for 64-bit SDK):
[git-for-windows-mingw32]
Server = https://wingit.blob.core.windows.net/i686
Authorize signing key (this step may have to be repeated occasionally until https://github.com/msys2/msys2/issues/62 is fixed)
curl -L https://raw.githubusercontent.com/git-for-windows/build-extra/master/git-for-windows-keyring/git-for-windows.gpg |
pacman-key --add - &&
pacman-key --lsign-key 1A9F3986
Then synchronize new repository
pacboy update
This updates msys2-runtime and therefore will ask you to close the window (not just exit the pacman process). Don't panic, simply close all currently open MSYS2 shells and MSYS2 programs. Once all are closed, start a new terminal again.
Then synchronize again (updating the non-core part of the packages):
pacboy update
And finally install the Git/cURL packages:
pacboy sync git:x git-doc-html:x git-doc-man:x git-extra: curl:x
Finally, check that everything went well by doing git --version in a MINGW64 shell and it should output something like git version 2.14.1.windows.1 (or newer).
Note: I found that the git-extra package installed by step 7 was quite intrusive (it adds a message "Welcome to the Git for Windows SDK!" to every terminal you open), so I removed it with pacman -R git-extra.
Note 2: I also found that Git for Windows' MSYS2 runtime opens in a different home directory than did MSYS2 proper's. This also means it reads in the wrong bash profile. I fixed this by adding an environment variable to Windows in the Control Panel: HOME=/C/msys64/home/myusername
I use git bash on my Windows machine and have run into this issue in the last month or so.
I still do not know what's causing it but I've found another way to stop it.
Open Task Manager
Go into the Processes tab
Look for node.exe and then press End Process
This has allowed me to stop the server quickly.
I had the same problem working with npm. But finally, I knew it was a problem with git itself.
There was a comment by dscho on GitHub 15 days ago. He said that they're working to fix this problem in the next release. He also shared the exact msys-2.0.dll file that can fix the problem for the people who can't wait.
Personally, I couldn't wait :p. So, I gave it a try, downloaded the file, and throw it in the git folder as he said. And the problem gone! It was awesome!
But please be sure to take a backup before you replace the file.
I also tried to kill it after running express as I used to; using taskkill /im node.exe on the cmd but there was no process to be found.
Check out this issue on GitHub,and search for the name of the file msys-2.0.dll to get to the comment faster.
Sometimes the node process hangs.
Check for the process ID using ps You may want to grep for node and then kill the process using kill -9 [PID]
Use Ctrl+\ to send the SIGQUIT signal. It will close the server.
Reference - https://en.wikipedia.org/wiki/Signal_(IPC)
I was able to fix this by switching to nodemon to run the server.
npm install --save-dev nodemon
package.json:
"scripts": {
"start": "nodemon app"
},
I was trying to get json-server to quit a custom server script, but it always left a child process running on Windows. It seems to be a specific problem running express via npm on Windows. If you run the server directly via the c:>node server.js then it seems to quit correctly.
I was able to debug this issue by checking the ports using TCP View, and realizing that my Node server was running even though I had pressed ctrl-C to stop it. I suggest killing the terminal you are running node from entirely.
Use Ctrl + C, then input: >pm2 stop all
This will stop all server or when you get stack with nodejs.
Inside package.json under scripts I had this line react-scripts start&. Notice it ends with an & which would send the process to the background and ctrl+c will not work. Somehow trying to bring this to the foreground with fg also did not work. Solved the problem by removing the &.
if you use Node.js Exec Extention to run your project from f8,
you can use also f9 to cancel running..
This is more than likely just a problem with your console not accurately sending the command to the process. This is pretty common, especially when using third party consoles like cmdr / conemu.
The solution?
Just hit ctrl+c several times until it closes :P
I'm trying to debug nodejs script (on Windows). I found that I can stop execution / set a breakpoint withing the script by using the 'debugger;' statement. However this seems to work only if node.exe called as:
node debug myscript.js
Problem is I'm not the one who's calling node.exe, so I can't pass the debug argument. Actually node.exe is being called many times before myscript.js. And myscript.js is in turn being called from some other.js. Running myscript.js directly (outside other.js) does not work.
Is there a way to wait for the debugger to attach?
If possible the solution should make use of some GUI debugger (like npm node-inspector).
Update 1:
To wait for the debugger in your application use:
npm install sleep # install locally, not global
Add code to myscript.js:
var sleep = require('sleep');
...
var done = 1;
while ( done != 1 ) {
console.log("PID=" + process.pid);
sleep(1);
}
...
Run your script (i.e. start whatever triggers its execution):
PID=3280
PID=3280
Start node-inspector:
C:\Users\Samo>node-inspector
Node Inspector v0.12.7
Visit http://127.0.0.1:8080/?port=5858 to start debugging.
Open a new cmd.exe and run:
C:\Users\Samo>tasklist /FI "IMAGENAME eq node.exe"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
node.exe 3944 Console 1 64,016 K
node.exe 3280 Console 1 119,276 K
From the same cmd.exe issue:
node -e "process._debugProcess(3280)"
In the debugged script's output, you should see:
PID=3280
Starting debugger agent.
Debugger listening on port 5858
Now go to the indicated URL (http://127.0.0.1:8080/?port=5858) using Chrome (not Firefox, but Chrome). You should be able to debug, now.
I said should because in my case it does not work. If I send _debugProcess to 3280 (my myscript.js) nothing happens. However if I send _debugProcess to 3944 I get the "Starting debugger agent." message. Why?
If you have the typical windows workspace such as Node, git and VSCode,
you can do it in these simple steps:
In VSCode, open launch.json configuration or create new by clicking on the wheel
(this is the debug view CtrlShiftD)
The node will listen on port 9229 by default, so add this configuration:
{
"type": "node",
"request": "attach",
"name": "Attach to 9229",
"port": 9229
},
Open Task Manager and locate the PID of your node process
I could identify my by the "build" folder where the index.js is.
open another cmd or git-bash and run this command,
where 21392 is the PID of your process.
node -e "process._debugProcess(21392)"
you should see this
Start debugging from VSCode Attach to 9229
Everything should be ready now.
I just discovered that my nodejs app keeps crashing, so I've used forever app.js to start my app and have it automatically restarted when it crashes.
Problem: Now my app outputs alot of useful information as it runs via console.log and util.log. I used to use screen to run the node app, but now that I'm using forever to run the nodejs app, I can no longer see all the outputs.
Is there any way to see all the output from the nodejs app in realtime?
Directly with forever command :
forever logs app.js -f
It shows in realtime output of your application and forever logs (shows detected changes & restart messages).
You can watch a logfile live by using this shell-command.
tail -f /path/to/logfile
Not sure if this is what you needed.
Simplest way to go is
Run :
forever logs // will give you list of log files
forever logs 0 -f // then just provide the index of log
If you pass the --help flag to Forever you'll see this example:
forever -o out.log -e err.log my-script.js
-o and -e define the stdout and stderr log files.
-o OUTFILE Logs stdout from child script to OUTFILE
-e ERRFILE Logs stderr from child script to ERRFILE
Forever seems a little overkill for development. Give Supervisor a shot and see if you like it better:
npm install -g supervisor
supervisor app.js
I am running nodejs on AWS EC2 instance and this worked for me.
Note: logs are accessible if you are root owner. So first use sudo su then
forever -a -o out.log -e err.log yourServerApp.js
It will tail console log (in case you track event messages from log) and error log. I hope it helps someone.
linux : tail -f /path/to/logfile.log
windows : enter PowerShell -> Get-Content /path/to/logfile.log -Wait -Tail 1000