-
Notifications
You must be signed in to change notification settings - Fork 4
Home
Sometimes this logs "The process terminated unexpectedly.". Often times the script runs perfectly when used without using node-windows, but fails to start when node-windows is used. The most common cause for this is a faulty installation.
var svc = new Service({
name:'MyService',
description: 'Description',
script: __dirname + "index.js" // <--- PROBLEM IS HERE
});
The problem above is the use of the __dirname
variable, which is a a relative reference (as opposed to an absolute reference). Since node-windows uses a wrapper, __dirname
refers to the root of the node-windows module, not your script. Per the instructions on the README, always use an absolute path.
Node-windows is not supported on operating systems that have reached EOL (End of Life) with Microsoft.
Supervisor, Forever, and NSSM all provide the same functionality as node-windows. Using them together would be like using a hammer to use a hammer to pound a nail, i.e. it's redundant. Use node-windows OR one of these others.
Node-windows used to be based on NSSM, but it was more limited than winsw.exe (which node-windows is currently based on). Supervisor and Forever are both great modules, but they're a little different from node-windows. Node-windows uses the operating systems' native uptime functionality instead of recreating it within node. This allows it to interact with existing system monitors (Nagios, System Center Essentials, etc).
They get logged to stdout
, which means they won't show up in the event log. Normally, this is just dumped to the console, but since node-windows processes aren't running in a console, these messages are essentially lost without some other means of capturing them. As of right now, it's best to use the built in logging capabilities of node-windows or another dedicated logging module to write application info to a file.
That said, I have considered adding a configuration attribute to allow for redirecting console.log to the event log.... but the event log isn't really supposed to be a full syslog... so I'm on the fence between principle and pragmatism.
The most common reason for this type of behavior is the configuration of a path. For example, a lot of people use __dirname
to define a path within their script without understanding __dirname
is a relative path. It can and often does differ between a child and parent process. As the documentation suggests, it is always best to use absolute paths, not relative paths. Remember that node-windows spawns your script as a new child process, which is why the working directory is different from when you run node myscript.js
. This is not specific to node-windows, this is the context most Windows background services run in.
Another common issue is a misunderstanding of how a third party module is used within an app. Some modules make assumptions about the context in which they're running. Make sure you understand what your third party modules are doing, don't just use them blindly. Running a node script as a daemon is very different from running as a server or worker.