-
-
Notifications
You must be signed in to change notification settings - Fork 356
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.
The most common reason for this behavior is a misconfiguration within your script, or lack of a permission.
Common Filepath Oversights:
If a script is importing/requiring another file (such as another script, xxx.json, package.json, etc), it is important to make sure the process understands exactly where those files exist. Remember, using relative paths (i.e. ./path/to/wherever), __dirname, and/or __filepath are not advised because the root directory will not be the same when the script is run as a process. See My script runs fine on it's own, but not with node-windows. Why? and the question above.
Common Permission Oversights:
Sometimes scripts do not have read/write permissions to files, primarily because authors forget to consider that the user account used to launch the service may not have the same permissions the developer has when developing the project.
Another common issue for developing API and web server applications are port permissions. Remember, Windows restricts port use on ports below 1024. See My HTTP service runs, but my HTTPS service doesn't!
Node-windows is not supported on operating systems that have reached EOL (End of Life) with Microsoft. That said, it will work in some Windows XP environments, but I have no plans to offer support for this.
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.
Short answer: No.
Detailed answer: node-windows is designed to run on systems with Node.js installed. It is a wrapper for managing the not-so-intuitive parts of dealing with background services and logging on Windows (or Mac/Linux). The purpose of this project is not to create fully bound binaries. Node.js is updated frequently, often times with vulnerability patches. By maintaining separation, it is possible to apply new versions of Node.js to a computer without modifying the generated node-windows executable.
For version management, please see NVM for Windows.
If you really want to ship a completely self-contained Node-based application, Electron and NW.js are good options. I haven't used it, but nexe looks promising if you just want to ship a single executable.
Most operating systems require special privileges to run anything under port 1024. Many configurations make an exception for port 80 due to it's widespread use as a web server. Port 443 (default for HTTPS) may be subject to these permission restrictions.
Most versions of Windows actually support using ports under 1024 by default, but locked down environments may restrict use of ports under 1024. In this case, the only resolution is to launch your service under a user account that has administrative privileges or request a firewall exception.
Node-windows can be used within an Electron/NW.js app, but only if you want the app to generate new services dynamically. Node-windows should not be used to run an Electron/NW.js app. Electron/NW.js both have their own daemon/service manager, making node-windows unnecessary for Electron/NW.js.
There is a great thread about using node-windows with Electron in issue 245