svenweller
Notes about Oracle SQL, PLSQL and APEX
How to run Node.js (Websocket) as windows service
In a recent project we are using websockets to respond in Apex to certain database events.
The websocket server is based upon node.js. One of the tasks was to setup this server as an service under a normal Windows Server 2003 (yes I know it is old) infrastructure. This post describes the steps how to setup such a service and also includes some monitoring information.
The prerequisties are that you already need to have node installed on your machine.
To start the websocket server we would usually call
This starts the server. All the output (console.log) will be written to the terminal.
But we don’t want to run it manually each time. Instead we would like to setup it as a windows service. So here is how to achieve that. The same logic can be applied for any node module, not just for websockets.
1) Load node-windows
The node package that I used is node-windows. It is very lightweight and did not have dependencies to node-gyp which often gives trouble.
The command to install it is:
The author recommends to install it using the global flag -g. You might want to consider it. I did not encounter issues without the global flag.
2) Install the service
In the node “shell” run the following commands.
The script name is the same script that would be called directly from node.
The name and the description can then be seen in the windows service tool.
Result
And we are able to start and stop the service.
Ok there is a tiny bit more. We want to be able to uninstall it as well. And we need to think about the messages that were previously written to the console.
Run in Batch
The sequence of javascript commands can also be put into a .BAT file. I choose to separate the batch call from the js code, so there are two files now.
3) Uninstall the service
The logic to deinstall the service is very similar to installing it.
4) Add event logging
Node-windows comes with same basic windows event logging. That means certain type of actions can be written into the default windows eventlog.
An this is how the result looks like in the Event Viewer (search for Event on your Windows Server) to find the tool. 
Windows node js as service
NOTE This module has been deprecated in favour of the os-service module, please use that module instead. The two modules differ in that the add() and remove() functions require a callback.
This module implements the ability to run a Node.js based JavaScript program as a native Windows service.
This module is installed using node package manager (npm):
It is loaded using the require() function:
A program can then be added, removed and run as a Windows service:
Batch Service Creation
Two approaches can be taken when adding and removing services.
In the first approach a program can be responsible for adding, removing and starting itself as a service. This is typically achieved by supporting program arguments such as —add , —remove , and —run , and executing the appropriate action.
The following example adds the calling program as a service when called with a —add parameter, and removes the created service when called with a —remove parameter:
Note the —run argument passed in the options parameter to the service.add() function. When the service is started using the Windows Service Control Manager the first argument to the program will be —run . The above program checks for this and if specified runs as a service using the service.run() function.
Also note that neither the node binary or the programs fully qualified path are specified. These parameters are automatically calculated it not specified. Refer to the service.add() function description for details about how this works.
In the second approach a dedicated service management program can be responsible for adding and removing many services in batch. The program adding and removing services is not a service itself, and would never call the service.run() function.
The following example adds or removes number of services:
Note that unlike the previous example the —run argument is not passed in the options parameter to the service.add() function. Since each service program does not add or remove itself as a service it only needs to run, and as such does not need to be told to so.
Also note that the programPath argument is passed in the options parameter to the service.add() function, to specify the fully qualified path to each service program — which would otherwise default to the service management program adding the services.
Each of the service programs can simply start themselves as services using the following code:
Running Service Programs
When a service program starts it can always call the service.run() function regardless of whether it is started at the console, or by the Windows Service Control Manager.
When the service.run() function is called this module will attempt to connect to the Windows Service Control Manager so that control requests can be received — so that the service can be stopped.
When starting a program at the console an attempt to connect to the Windows Service Control Manager will fail. In this case the service.run() function will assume the program is running at the console and silently ignore this error.
This behaviour results in a program which can be run either at the console or the Windows Service Control Manager with no change.
Current Working Directory
Upon starting the current working directory of a service program will be the «%windir%\system32» directory (i.e. c:\windows\system32 ). Service programs need to consider this when working with relative directory and file paths.
This path will most likely be different when running the same program at the console, so a service program may wish to change the current working directory to a more suitable location using the process.chdir() function to avoid different behaviour between the two methods of starting a program.
Given the intended purpose of this module only Windows platforms are supported.
However, this module aims to support other platforms in the future. That is it aims to support installing as a service on other platforms — by creating /etc/init.d/. scripts for example — so that the same service management code can be used to abstract away platform differences.
service.add (name, [options])
The add() function adds a Windows service.
The name parameter specifies the name of the created service. The optional options parameter is an object, and can contain the following items:
- displayName — The services display name, defaults to the name parameter
- nodePath — The fully qualified path to the node binary used to run the service (i.e. c:\Program Files\nodejs\node.exe , defaults to the value of process.execPath
- nodeArgs — An array of strings specifying parameters to pass to nodePath , defaults to []
- programPath — The program to run using nodePath , defaults to the value of process.argv[1]
- programArgs — An array of strings specifying parameters to pass to programPath , defaults to []
The service will be set to automatically start at boot time, but not started. The service can be started using the net start «My Service» command.
An exception will be thrown if the service could not be added. The error will be an instance of the Error class.
The following example installs a service named My Service , it explicitly specifies the services display name, and specifies a number of parameters to the program:
The remove() function removes a Windows service.
The name parameter specifies the name of the service to remove. This will be the same name parameter specified when adding the service.
The service must be in a stopped state for it to be removed. The net stop «My Service» command can be used to stop the service before it is to be removed.
An exception will be thrown if the service could not be removed. The error will be an instance of the Error class.
The following example removes the service named My Service :
service.run (stdoutLogStream, [stderrLogStream,] callback)
The run() function will connect the calling program to the Windows Service Control Manager, allowing the program to run as a Windows service.
The programs process.stdout stream will be replaced with the stdoutLogStream parameter, and the programs process.stderr stream replaced with the stdoutLogStream parameter (this allows the redirection of all console.log() type calls to a service specific log file). If the stderrLogStream parameter is not specified the programs process.stderr stream will be replaced with the stdoutLogStream parameter. The callback function will be called when the service receives a stop request, e.g. because the Windows Service Controller was used to send a stop request to the service.
The program should perform cleanup tasks and then call the service.stop() function.
The following example connects the calling program to the Windows Service Control Manager, it uses the same log stream for standard output and standard error:
The stop() function will cause the service to stop, and the calling program to exit.
Once the service has been stopped this function will terminate the program by calling the process.exit() function, passing to it the rcode parameter which defaults to 0 . Before calling this function ensure the program has finished performing cleanup tasks.
BE AWARE, THIS FUNCTION WILL NOT RETURN.
The following example stops the calling program specifying a return code of 0 , the function will not return:
Example programs are included under the modules example directory.
How to install node.js as windows service?
I have downloaded node.js executable. How can I run that executable as windows service? I cannot use standard node.js installer, since I need to run multiple version of node.js concurrently.
6 Answers 6
Late to the party, but node-windows will do the trick too.
It also has system logging built in.
There is an API to create scripts from code, i.e.
FD: I’m the author of this module.
I found the thing so useful that I built an even easier to use wrapper around it (npm, github).
Installing your service:
Uninstalling your service:
WinSer is a node.js friendly wrapper around the popular NSSM (Non-Sucking Service Manager)
Next up, I wanted to host node as a service, just like IIS. This way it’d start up with my machine, run in the background, restart automatically if it crashes and so forth.
This is where nssm, the non-sucking service manager, enters the picture. This tool lets you host a normal .exe as a Windows service.
Here are the commands I used to setup an instance of the your node application as a service, open your cmd like administrator and type following commands:
I’m not addressing the question directly, but providing an alternative that might also meet your requirement in a more node.js fashion way.
Functionally the requirements are:
- Have the logic (app) running in the background
- Be able to start/stop the logic
- Automatically start the logic when system boots up
These requirements can be satisfied by using a process manager (PM) and making the process manager start on system startup. Two good PMs that are Windows-friendly are:
To make the PM start automatically, the most simple way is to create a scheduled task with a «At Startup» trigger:
The process manager + task scheduler approach I posted a year ago works well with some one-off service installations. But recently I started to design system in a micro-service fashion, with many small services talking to each other via IPC. So manually configuring each service has become unbearable.
Towards the goal of installing services without manual configuration, I created serman, a command line tool (install with npm i -g serman ) to install an executable as a service. All you need to write (and only write once) is a simple service configuration file along with your executable. Run
will install the service. stdout and stderr are all logged. For more info, take a look at the project website.
A working configuration file is very simple, as demonstrated below. But it also has many useful features such as and