Support for Windows services, event logging, UAC, and several helper methods for interacting with the OS. 

cbutler

node-windows

 * This utility can be used to manage node.js scripts as Windows services.

 * **Please note that like all Windows services, creating one requires administrative privileges**.

 * To create a service with node-windows, prepare a script like:

 *      var Service = require('node-windows').Service;

 *        description: 'The nodejs.org example web server.',

 *        script: 'C:\\path\\to\\helloworld.js')

 *      // Listen for the "install" event, which indicates the

 *      // process is available as a service.

 * The code above creates a new `Service` object, providing a pretty name and description.

 * The `script` attribute identifies the Node.js script that should run as a service. Upon running

 * this, the script will be visible from the Windows Services utility.

 * ![Windows Service](https://raw.github.com/coreybutler/node-windows/master/docs/service.png)

var exec = require('child_process').exec,

    PermError = 'Permission Denied. Requires administrative privileges.',

    wrapper = path.resolve(path.join(__dirname,'./wrapper.js'));

// BEGIN SUPER AWFUL HACK TO GET AROUND WINSW.EXE ISSUE! REPLACE ASAP!!!!

// winsw.exe immediately responds with nothing, indicating success, even though

// it continues processing with the "install" method.

  while(new Date().getTime() <= st+(period*1000)){}

   * An optional array or object used to pass environment variables to the node.js script.

   * You can do this by setting environment variables in the service config, as shown below:

   *      description: 'The nodejs.org example web server.',

   *      script: 'C:\\path\\to\\helloworld.js',

   * You can also supply an array to set multiple environment variables:

   *        value: process.env["USERPROFILE"] // Access the user home directory

          allowServiceLogon: config.allowServiceLogon

     * The maximum number of restart attempts to make before the service is considered non-responsive/faulty.

      value: config.hasOwnProperty('maxRetries') ? config.maxRetries : null

     * @cfg {Boolean} [stopparentfirst=false]

     * Allow the service to shutdown cleanly.

     * How long to wait in seconds before force killing the application.

     * This only takes effect when stopparentfirst is enabled.

      value: config.hasOwnProperty('stoptimeout') ? config.stoptimeout : 30

     * @cfg {string} [nodeOptions='--harmony']

     * Options to be passed to the node process.

      value: config.nodeOptions || '--harmony'

     * Options to be passed to the script.

     * The maximum number of restarts within a 60 second period before haulting the process.

     * This cannot be _disabled_, but it can be rendered ineffective by setting a value of `0`.

      value: config.hasOwnProperty('maxRestarts') ? config.maxRestarts : 3

     * @cfg {Boolean} [abortOnError=false]

     * Setting this to `true` will force the process to exit if it encounters an error that stops the node.js script from running.

     * This does not mean the process will stop if the script throws an error. It will only abort if the

     * script throws an error causing the process to exit (i.e. `process.exit(1)`).

      value: config.abortOnError instanceof Boolean ? config.abortOnError : false

     * The initial number of seconds to wait before attempting a restart (after the script stops).

   * Generate the XML for the winsw configuration file.

   * The config object must have the following attributes:

   * - *id* This is is how the service is identified. Alphanumeric, no spaces.

   * - *name* The descriptive name of the service.

   * - *script* The absolute path of the node.js server script. i.e. in this case

   *  it's the wrapper script, not the user's server script.

   * - *description* The description that shows up in the service manager.

   * - *nodeOptions* Array or space separated string of node options (e.g. '--harmony')

   * - *wrapperArgs* additional arguments to pass to wrapper script to control restarts, etc.

   * - *logmode* Valid values include `rotate` (default), `reset` (clear log), `roll` (move to .old), and `append`.

   * - *logging* Supersedes *logmode*. Object of form `{mode: 'append'}`,

   * `{mode: 'reset'}`, `{mode: 'none'}`, `{mode: 'roll-by-time', pattern: 'yyyMMdd'}`,

   * or `{mode: 'roll-by-size', sizeThreshold: 10240, keepFiles: 8}` (all attributes optional,

   * example shows defaults). See [winsw docs](https://github.com/kohsuke/winsw/tree/winsw-1.17#logging).

   * - *logpath* The absolute path to the directory where logs should be stored. Defaults to the current directory.

   * - *dependencies* A comma delimited list or array of process dependencies.

   * - *env* A key/value object or array of key/value objects containing

   * environment variables to pass to the process. The object might look like `{name:'HOME',value:'c:\Windows'}`.

   * - *logOnAs* A key/value object that contains the service logon credentials.

   * The object might look like `{account:'user', password:'pwd', domain:'MYDOMAIN'}

   * If this is not included or does not have all 3 members set then it is not used.

   * - *workingdirectory* optional working directory that service should run in.

   * If this is not included, the current working directory of the install process

    // add multiple "tag" items to the xml

    // if input is an array, add each element of the array, if it's a string,

    // split it around splitter and add each one

    // if input is null or undefined do nothing

      if (input===undefined || input===null) {

        input = input.split(splitter||',');

    // Make sure required configuration items are present

    if (!config || !config.id || !config.name || !config.script)

      throw "WINSW must be configured with a minimum of id, name and script";

    // only the portion of the xml inside the top level 'service' tag

      {description: config.description||''},

      {executable: config.execPath || process.execPath}

    multi('argument',config.nodeOptions, ' ');

    xml.push({argument:config.script.trim()});

    multi('argument',config.wrapperArgs,' ');

    // Optionally add logging values, defaulting to logmode

      var logcontent = [{_attr: {mode: (config.logging.mode || 'append')}}];

      if (config.logging.mode === 'roll-by-time') {

        logcontent.push({pattern: (config.logging.pattern || 'yyyMMdd')});

      if (config.logging.mode === 'roll-by-size') {

        logcontent.push({sizeThreshold: (config.logging.sizeThreshold || 10240)});

        logcontent.push({keepFiles: (config.logging.keepFiles || 8)});

      xml.push({logmode: config.logmode||'rotate'});

      xml.push({logpath : config.logpath});

    // Optionally add stopparentprocessfirst

        { domain: config.logOnAs.domain || 'NT AUTHORITY' },

        { user: config.logOnAs.account || 'LocalSystem' },

        { password: config.logOnAs.password || '' }

        serviceaccount.push({ allowservicelogon: 'true' })

          {domain: config.logOnAs.domain || 'NT AUTHORITY'},

          {user: config.logOnAs.account || 'LocalSystem'},

          {password: config.logOnAs.password || ''},

    // if no working directory specified, use current working directory

    // that this process was launched with

    xml.push({workingdirectory: config.workingdirectory || process.cwd()});

    // indent resultant xml with tabs, and use windows newlines for extra readability

    return require('xml')({service:xml}, {indent: '\t'}).replace(/\n/g,'\r\n');

   * Copy install version of winsw.exe to specific renamed version according to

   * the service id. Also copy .exe.config file that allows it to run under

   * .NET 4+ runtime on newer versions of windows.

   * (see https://github.com/kohsuke/winsw#net-runtime-40)

   * The alphanumeric string (spaces are stripped) of the `.exe` file. For example, `My App` generates `myapp.exe`

   * The output directory where the executable will be saved.

   * The callback to fire upon completion.

  createExe: function(name,dir,callback) {

    var fs = require('fs'), p = require('path');

    var exeOrigin = p.join(__dirname,'..','bin','winsw','winsw.exe'),

        cfgOrigin = p.join(__dirname,'..','bin','winsw','winsw.exe.config'),

        exeDest = p.join(dir,name.replace(/[^\w]/gi,'').toLowerCase()+'.exe'),

        cfgDest = p.join(dir,name.replace(/[^\w]/gi,'').toLowerCase()+'.exe.config'),

        exeData = fs.readFileSync(exeOrigin,{encoding:'binary'}),

        cfgData = fs.readFileSync(cfgOrigin,{encoding:'binary'});

    fs.writeFileSync(exeDest,exeData,{encoding:'binary'});

    fs.writeFileSync(cfgDest,cfgData,{encoding:'binary'});

  "description": "Support for Windows services, event logging, UAC, and several helper methods for interacting with the OS.",

  "author": "Corey Butler <corey@coreybutler.com>",

    "url": "git://github.com/coreybutler/node-windows.git"

![NPM version](https://img.shields.io/npm/v/node-windows?label=node-windows&logo=npm&style=for-the-badge)

![NGN Dependencies](https://david-dm.org/coreybutler/node-windows.svg?style=for-the-badge)

[Tweet me (@goldglovecb)](http://twitter.com/goldglovecb) if you need me.

Several PR's that have been outstanding for months (or even years) have been merged (unless there were merge conflicts), which is why this version is tagged as "1.0.0-beta.1", despite the fact v0.1.14 has been used in production for years by over 600,000 processes. I would use the latest version in production apps.

  This is a standalone module, originally designed for internal use in [NGN](http://github.com/thinkfirst/NGN). However; it is capable of providing the same features for Node.JS scripts independently of NGN.

  For alternative versions, see [node-mac](http://github.com/coreybutler/node-mac) and [node-linux](http://github.com/coreybutler/node-linux).

The following features are available in node-windows:

- **Service Management**: Run Node.js scripts as native Windows services. Includes monitoring.

- **Event Logging**: Create logs in the Event log.

  - _Elevated Permissions_: Run a command with elevated privileges (may prompt user for acceptance)

  - _Sudo_: Run an `exec` command as a sudoer.

  - _Identify Administrative Privileges_: Determines whether the current user has administrative privileges.

  - _List Tasks_: A method to list running windows tasks/services.

  - _Kill Task_: A method to kill a specific windows service/task (by PID).

The recommended way to install node-windows is with npm, using the global flag:

However; it is possible to use node-windows without the global flag (i.e. install directly into the project root).

More details regarding why this is not the recommended approach are available throughout this Readme.

Using native node modules on Windows can suck. Most native modules are not distributed in a binary format.

Instead, these modules rely on `npm` to build the project, utilizing [node-gyp](https://github.com/TooTallNate/node-gyp).

This means developers need to have Visual Studio (and potentially other software) installed on the system,

just to install a native module. This is portable, but painful... mostly because Visual Studio

**node-windows does not use native modules.** There are some binary/exe utilities, but everything

needed to run more complex tasks is packaged and distributed in a readily usable format. So, no need for

Visual Studio... at least not for this module.

node-windows has a utility to run Node.js scripts as Windows services. Please note that like all

Windows services, creating one requires administrative privileges. To create a service with

var Service = require('node-windows').Service;

  description: 'The nodejs.org example web server.',

// Listen for the "install" event, which indicates the

The code above creates a new `Service` object, providing a pretty name and description.

The `script` attribute identifies the Node.js script that should run as a service. Upon running

this, the script will be visible from the Windows Services utility.

![Windows Service](https://raw.github.com/coreybutler/node-windows/master/docs/service.png)

The `Service` object emits the following events:

- _install_ - Fired when the script is installed as a service.

- _alreadyinstalled_ - Fired if the script is already known to be a service.

- _invalidinstallation_ - Fired if an installation is detected but missing required files.

- _uninstall_ - Fired when an uninstallation is complete.

- _alreadyuninstalled_ - Fired when an uninstall is requested and no installation exists.

- _start_ - Fired when the new service is started.

- _stop_ - Fired when the service is stopped.

- _error_ - Fired in some instances when an error occurs.

In the example above, the script listens for the `install` event. Since this event

is fired when a service installation is complete, it is safe to start the service.

Services created by node-windows are similar to most other services running on Windows.

They can be started/stopped from the windows service utility, via `NET START` or `NET STOP` commands,

or even managed using the <a href="http://technet.microsoft.com/en-us/library/dd228922(v=ws.10).aspx">sc</a>

It may be desired to specify command-line switches to your script. You can do this by setting the `scriptOptions` within the service config:

  scriptOptions: '-c C:\\path\\to\\somewhere\\special -i'

Sometimes you may want to provide a service with static data, passed in on creation of the service. You can do this by setting environment variables in the service config, as shown below:

    value: process.env["USERPROFILE"] // service is now able to access the user who created its' home directory

You can also supply an array to set multiple environment variables:

    value: path.join(process.env["USERPROFILE"],"/temp") // use a temp directory in user's home directory

There are times when you may want to specify a specific `node` executable to use to run your script. You can do this by setting the `execPath` in the service config, as shown below:

  execPath: 'C:\\path\\to\\specific\\node.exe'

If you need to specify a specific user or particular credentials to manage a service, the following

  script: require('path').join(__dirname,'helloworld.js')

  script: require('path').join(__dirname,'helloworld.js'),

Both the account and password must be explicitly defined if you want the service module to

run commands as a specific user. By default, it will run using the user account that launched

the process (i.e. who launched `node app.js`).

If you want to instruct winsw to allow service account logins, specify `allowServiceLogon: true`. This is disabled by default since some users have experienced issues running this without service logons.

The other attribute is `sudo`. This attribute has a single property called `password`. By supplying

this, the service module will attempt to run commands using the user account that launched the

process and the password for that account. This should only be used for accounts with administrative

Uninstalling a previously created service is syntactically similar to installation.

// Listen for the "uninstall" event so we know when it's done.

  console.log('The service exists: ',svc.exists);

		@@ -134,3 +134,4 @@ /**
		logmode: this.logmode,
		logging: config.logging
		logging: config.logging,
		allowServiceLogon: config.allowServiceLogon
		});
		@@ -137,0 +138,0 @@ }

		{
		"name": "node-windows",
		"version": "1.0.0-beta.4",
		"version": "1.0.0-beta.5",
		"description": "Support for Windows services, event logging, UAC, and several helper methods for interacting with the OS.",
		@@ -5,0 +5,0 @@ "keywords": [

		@@ -93,2 +93,3 @@ # node-windows
		//, workingDirectory: '...'
		//, allowServiceLogon: true
		});
		@@ -209,3 +210,4 @@
		name:'Hello World',
		script: require('path').join(__dirname,'helloworld.js')
		script: require('path').join(__dirname,'helloworld.js'),
		//, allowServiceLogon: true
		});
		@@ -223,2 +225,4 @@

		If you want to instruct winsw to allow service account logins, specify `allowServiceLogon: true`. This is disabled by default since some users have experienced issues running this without service logons.

		The other attribute is `sudo`. This attribute has a single property called `password`. By supplying
		@@ -225,0 +229,0 @@ this, the service module will attempt to run commands using the user account that launched the

New alerts

Fixed alerts

Improved metrics

Worsened metrics

		@@ -124,9 +124,14 @@ module.exports = {
		if (config.logOnAs) {
		var serviceaccount = [
		{ domain: config.logOnAs.domain \|\| 'NT AUTHORITY' },
		{ user: config.logOnAs.account \|\| 'LocalSystem' },
		{ password: config.logOnAs.password \|\| '' }
		]

		if (config.allowServiceLogon) {
		serviceaccount.push({ allowservicelogon: 'true' })
		}

		xml.push({
		serviceaccount: [
		{domain: config.logOnAs.domain \|\| 'NT AUTHORITY'},
		{user: config.logOnAs.account \|\| 'LocalSystem'},
		{password: config.logOnAs.password \|\| ''},
		{allowservicelogon: 'true'}
		]
		serviceaccount: serviceaccount
		});
		@@ -133,0 +138,0 @@ }