NSSM

Non-Sucking Service Manager(NSSM)

nssm is a service helper which doesn't suck. srvany and other service helper programs suck because they don't handle failure of the application running as a service. If you use such a program you may see a service listed as started when in fact the application has died. nssm monitors the running service and will restart it if it dies. With nssm you know that if a service says it's running, it really is. Alternatively, if your application is well-behaved you can configure nssm to absolve all responsibility for restarting it and let Windows take care of recovery actions.

nssm logs its progress to the system Event Log so you can get some idea of why an application isn't behaving as it should.

nssm also features a graphical service installation and removal facility. Prior to version 2.19 it did suck. Now it's quite a bit better.

Service installation

nssm install <servicename>
nssm install <servicename> <program>
nssm install <servicename> <program> [<arguments>]
nssm install AMQPD D:\opt\pro\chorke\bin\amqpd start

By default the service's startup directory will be set to the directory containing the program. The startup directory can be overridden after the service has been installed.

nssm set <servicename> AppDirectory <path>

Service removal

nssm remove
nssm remove <servicename>
nssm remove <servicename> confirm
nssm remove AMQPD confirm

Service management

As of version 2.22, nssm offers basic service management functionality. nssm will also accept a service displayname anywhere that a servicename is expected, since Windows does not allow a service to have a name or display name which conflicts with either the name or display name of another service. Both the service name (also called the service key name) and its display name uniquely identify a service.

Starting and stopping a service

nssm start <servicename>
nssm stop <servicename>
nssm restart <servicename>

Querying a service's status

nssm status <servicename>

Sending controls to services

nssm pause <servicename>
nssm continue <servicename>
nssm rotate <servicename>

nssm rotate triggers on-demand rotation for nssm services with I/O redirection and online rotation enabled. nssm accepts user-defined control 128 as a cue to begin output file rotation. Non-nssm services might respond to control 128 in their own way (or ignore it, or crash).

Service editing

As of version 2.22, all parameters understood by nssm can be queried or configured on the command line. A subset of system parameters can also be queried and, in some cases, modified.

General syntax

Parameters can usually be queried as follows.

nssm get <servicename> <parameter>

Some parameters are ambiguous and require a subparameter. See below.

nssm get <servicename> <parameter> <subparameter>

Parameters can usually be set in a similar way.

nssm set <servicename> <parameter> <value>
nssm set <servicename> <parameter> <subparameter> <value>

Most parameters can be reset to their defaults, which is equivalent to removing the associated registry entry.

nssm reset <servicename> <parameter>
nssm reset <servicename> <parameter> <subparameter>

As a convenience, nssm will accept additional arguments beyond the value required, and concatenate them together, separated by single spaces. Thus the following two invocations are identical:

nssm set <servicename> AppParameters "-classpath C:\Classes"
nssm set <servicename> AppParameters -classpath C:\Classes

Parameters

A parameter is usually a string with the same name as the registry entry which controls the associated functionality. So, for example, the following command sets the startup directory for a service:

nssm set <servicename> AppDirectory <path>

Values

Most parameters are configured by setting the same value as is documented for the associated registry entry. To enable file rotation, for example, you would use the following command:

nssm set <servicename> AppRotation 1

See below for a list of parameters whose values are set differently.

Native parameters

Certain parameters configure properties of the service itself rather than the behaviour of nssm. They too are named after their associated registry values.

1. DependOnGroup: Load order groups whose members must start before the service can start.
2. DependOnService: Services which must start before the service can start.
3. Description: The service's description
4. DisplayName: The service's display name, eg Application Layer Gateway Service. This is the name shown under the Name column in services.msc.
5. ImagePath: Path to the service executable, eg C:\Windows\System32\alg.exe. For nssm services, this will be the path to nssm.exe.
6. ObjectName: The name of the user account under which the service runs. The default is LOCALSYSTEM.
7. Name: The service key name, eg ALG. The key name cannot be changed. You can use nssm get <displayname> Name to find out the key name of a service.
8. Start: The service's startup type, eg Automatic.
9. Type: The service type. nssm can only edit services of type SERVICE_WIN32_OWN_PROCESS.

References

Yet Another Java Service Wrapper (yajsw) Running MinIO as a service on Windows Windows Service Wrapper (winsw) XML WinSW » Configuration file WinSW Java