8 Answers
8

process.on('exit', ..) isn't called if the process crashes or is killed. It is only called when the event loop ends, and since server.close()sort of ends the event loop (it still has to wait for currently running stacks here and there) it makes no sense to put that inside the exit event...

On crash, do process.on('uncaughtException', ..) and on kill do process.on('SIGTERM', ..)

What really solved it for me is doing two things. 1. Running my server as a daemon / job. 2. when running within bash, killing the process with ctrl + c. The odd error sometimes causes the app to crash unexpectedly, then I usally 'kill <pid>'
–
SkawfulNov 22 '10 at 19:32

You may use hot-node to prevent your server from crashing/ run-time-errors. Hot-node automatically restarts the nodejs application for you whenever there is a change in the node program[source] / process[running node program].

@matejkramny can you comment why this is the case?
–
mikeybaby173Feb 19 '14 at 0:08

pm2 is a better choice. more robust, more options. and doesn't have the problem when running as root that forever has.
–
LucasJul 24 '14 at 10:45

@Lucas What is this root problem in forever that you speak of? I am unfortunately forced to use forever instead of pm2 on a product at work (due to some licensing crap), and this worries me a lot!
–
GPXFeb 4 at 19:13

My issues was that I had two app.listen(3000); calls in the same app.js script. The first app.listen() succeeded where the second threw the error.

Another useful command I came across that helped me debug was sudo fuser -k 3000/tcp which will kill any rogue processes you might have started (some processes may restart, e.g. if run with forever.js, but it was useful for me).