We offer many ready-to-use apps, among them a serial-over-IP (SoI) app and Modbus Gateway app.
Let's assume you are creating a service Node.js application, i.e. an app that is supposed to start at boot and keep running for as long as your system is up. Achieving this requires an additional piece of software that will perform the actual job of starting and re-starting your app. One choice you have is called Forever.
Forever is the process manager of the Case Node.js — a Node.js runtime that is available on several major operating systems. There is nothing particularly bad about Forever, except that it is yet another Node.js process that will take up RAM (about 30MB), NAND space, and CPU resources while only providing a single primitive function: starting your program and restarting it after a failure.
A more rational choice for the LTPS is called SystemD. This is a system-wide, feature-rich, flexible, and modern Linux service manager that has everything you need: service startup dependencies, status control, restart on events, D-Bus integration, activation on connect, and so on. SystemD is very popular, and many articles on the Node.js and SystemD integration are available on the Internet. As an example, see this article and this one, too. These are written by people who work with Node.js services on a "pro level."
Here is an example of using SystemD for turning your app into a service. It assumes that your app.js is at /opt/node-apps/demo0/site/.
The steps:
# copy this file to /lib/systemd/system/
[Unit]
Description=LTPS NodeJS Test Application
After=network-online.target
[Service]
Restart=on-failure
WorkingDirectory=/opt/node-apps/demo0/site/
ExecStart=/usr/bin/node /opt/node-apps/demo0/site/app.js
[Install]
WantedBy=multi-user.target
Save it and copy to /lib/systemd/system/.
Run this command:
systemctl daemon-reload
systemctl enable myapp
systemctl restart myapp
That's it!
Anything your new myapp service outputs to the error or standard output stream will be redirected to the system journal. So, if something goes wrong you may use our System Journal Web Viewer to see the stack trace messages generated by Node.js exception handlers or console.log() output.
journalctl -lf -u myapp
systemctl stop myapp
systemctl disable myapp
systemctl status myapp
[Unit]
Description=LTPS NodeJS Test Application
After=network-online.target
[Service]
Restart=on-failure
# do chdir before running the service
WorkingDirectory=/opt/node-apps/demo0/site/
ExecStart=/usr/bin/node app.js
# limit CPU and RAM quota for our service
CPUAccounting=true
CPUQuota=10%
MemoryAccounting=true
MemoryLimit=50M
[Install]
WantedBy=multi-user.target