Autostarting Node.js application on CentOS 6.2

There are many ways to autorize Node.js applications, but after some searches I managed to find a solution that works and does not present much difficulty.

At first I tried forever - it works perfectly, but only until you need to start the application when the system boots. I tried to add a line to /etc/rc.d/rc.local - sometimes it worked, and sometimes it didn't, and so far I haven’t figured out why.

Then I looked at Upstart and at Monit . Upstart made writing a script for the autoloader as easy as autoexec.bat during DOS, and Monit can check the application to make sure it works all the time.
')
Then I realized that my need is simple: first, start the application when the system boots, and second, restart if it crashes (with the Node.js applications this happens) - and one upstart is enough to arrange and both.

Upstart is already included in CentOS 6.2, so all you have to do is put the text file in / etc / init - calling it, for example, myapp.conf:

#!upstart description "testjs.js " author "sample" start on runlevel [2345] stop on shutdown respawn script export HOME="/root" echo $$ > /var/run/testjs.pid exec /usr/local/bin/node /root/test.js >> /var/log/testjs.log 2>&1 end script pre-start script #    ,    (new Date()).toISOString(),    echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Starting" >> /var/log/testjs.log end script pre-stop script rm /var/run/testjs.pid echo "[`date -u +%Y-%m-%dT%T.%3NZ`] (sys) Stopping" >> /var/log/testjs.log end script 

After that it will be possible to give such commands:

 /sbin/start myapp /sbin/stop myapp /sbin/status myapp 

The application will also be launched at boot time, and on CentOS 6.2, you can do with this to start the application and to keep it running. I also found that running Centle through runlevel [2345] is necessary on CentOS, and other options do not seem to work.

---

Translator's Notes:

• Upstart does not need the description and author fields, so you can do without them in the script, instead of filling it with all sorts of nonsense.
  
• If the paths in the system are spelled correctly, then the script can simply type “ node ” instead of “/ usr / local / bin / node”; the same applies to the “ start ”, “ stop ” and “ status ” commands, which then will not need the “/ sbin /” prefix .
  
• In addition to the above, there is also a “ restart ” command, which starts “ stop ” first and then “ start ”. It is useful in cases where you have to restart one command (and not two), for example, the Express.js server, in order to clear any such cache that is stored in the server’s memory, or to force the server to be guided by a new version of the javascript file, describing the routing on the site.
  
• The “ start ” command can be given without fear: it will refuse to work if an application with the name specified to it is already running, and does not launch an unnecessary second copy of it.
  
• Without the line “ echo $$> /var/run/testjs.pid ” and without the opposite command “ rm /var/run/testjs.pid ”, as a rule, you can do. There is no need to kill the process by its number: it is much easier to issue the “ stop ” (or “ restart ”) command, which uses the name of the application, which is always the same, and, moreover, is remembered better.
  
• Specifying “ respawn ” works upstart so well that all the usual exit methods from the javascript application (for example, “ process.exit (0) ”) also cause it to restart, not to stop. You can use this if you need to provide an interface for remotely restarting a web server or some other server.
  
  Here is a simplified (but working) example for Express.js :
  
  

   app.get('/__', function(req, res){ res.type('text/plain'); res.send('The Express.js web server will shut down (and restart) in a second.'); console.log('Remote shutdown.'); setTimeout(function(){ process.exit(0); }, 1000); });