* These are Tibbo BASIC/C-programmable devices and their function depends on the loaded app.
We offer many ready-to-use apps, among them a serial-over-IP (SoI) app and Modbus Gateway app.
Node.js Application as a Service

Node.js Application as a Service

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:

  • Create the file myapp.service with the following contents:
# 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
  • Let SystemD know about the myapp service and instruct SystemD to load this service on boot:
systemctl enable myapp
  • Now run the myapp service:
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.

  • You may also find it convenient to see journaled messages directly in the CLI (To cancel this from the journal reader, press CTRL+C):
journalctl -lf -u myapp
  • To stop the service:
systemctl stop myapp
  • To disable the service (prevent it from loading on boot):
systemctl disable myapp
  • To see the status of your service:
systemctl status myapp
  • You may also want to set the main working directory for your service and limit the resources it takes from the OS:
[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
Node.js Application as a Service