Non-Sucking Service Manager
NSSM: The Non-Sucking Service Manager Version 2.24, 2014-08-31
NSSM is a service helper program similar to srvany and cygrunsrv. It can start any application as an NT service and will restart the service if it fails for any reason.
NSSM also has a graphical service installer and remover.
Full documentation can be found online at
http://nssm.cc/Since version 2.0, the GUI can be bypassed by entering all appropriate options on the command line.
Since version 2.1, NSSM can be compiled for x64 platforms. Thanks Benjamin Mayrargue.
Since version 2.2, NSSM can be configured to take different actions based on the exit code of the managed application.
Since version 2.3, NSSM logs to the Windows event log more elegantly.
Since version 2.5, NSSM respects environment variables in its parameters.
Since version 2.8, NSSM tries harder to shut down the managed application gracefully and throttles restart attempts if the application doesn't run for a minimum amount of time.
Since version 2.11, NSSM respects srvany's AppEnvironment parameter.
Since version 2.13, NSSM is translated into French. Thanks François-Régis Tardy.
Since version 2.15, NSSM is translated into Italian. Thanks Riccardo Gusmeroli.
Since version 2.17, NSSM can try to shut down console applications by simulating a Control-C keypress. If they have installed a handler routine they can clean up and shut down gracefully on receipt of the event.
Since version 2.17, NSSM can redirect the managed application's I/O streams to an arbitrary path.
Since version 2.18, NSSM can be configured to wait a user-specified amount of time for the application to exit when shutting down.
Since version 2.19, many more service options can be configured with the GUI installer as well as via the registry.
Since version 2.19, NSSM can add to the service's environment by setting AppEnvironmentExtra in place of or in addition to the srvany-compatible AppEnvironment.
Since version 2.22, NSSM can set the managed application's process priority and CPU affinity.
Since version 2.22, NSSM can apply an unconditional delay before restarting an application which has exited.
Since version 2.22, NSSM can rotate existing output files when redirecting I/O.
Since version 2.22, NSSM can set service display name, description, startup type, log on details and dependencies.
Since version 2.22, NSSM can manage existing services.
Since version 2.25, NSSM can execute commands in response to service events.
Since version 2.25, NSSM can list services it manages.
Since version 2.25, NSSM can dump the configuration of services it manages.
Since version 2.25, NSSM can show the processes managed by a service.
In the usage notes below, arguments to the program may be written in angle brackets and/or square brackets. means you must insert the appropriate string and [] means the string is optional. See the examples below...
Note that everywhere appears you may substitute the service's display name.
To install a service, run
nssm install You will be prompted to enter the full path to the application you wish to run and any command line options to pass to that application.
Use the system service manager (services.msc) to control advanced service properties such as startup method and desktop interaction. NSSM may support these options at a later time...
To install a service, run
nssm install []NSSM will then attempt to install a service which runs the named application with the given options (if you specified any).
Don't forget to enclose paths in "quotes" if they contain spaces!
If you want to include quotes in the options you will need to """quote""" the quotes.
NSSM will launch the application listed in the registry when you send it a start signal and will terminate it when you send a stop signal. So far, so much like srvany. But NSSM is the Non-Sucking service manager and can take action if/when the application dies.
With no configuration from you, NSSM will try to restart itself if it notices that the application died but you didn't send it a stop signal. NSSM will keep trying, pausing between each attempt, until the service is successfully started or you send it a stop signal.
NSSM will pause an increasingly longer time between subsequent restart attempts if the service fails to start in a timely manner, up to a maximum of four minutes. This is so it does not consume an excessive amount of CPU time trying to start a failed application over and over again. If you identify the cause of the failure and don't want to wait you can use the Windows service console (where the service will be shown in Paused state) to send a continue signal to NSSM and it will retry within a few seconds.
By default, NSSM defines "a timely manner" to be within 1500 milliseconds. You can change the threshold for the service by setting the number of milliseconds as a REG_DWORD value in the registry at HKLM\SYSTEM\CurrentControlSet\Services\Parameters\AppThrottle.
Alternatively, NSSM can pause for a configurable amount of time before attempting to restart the application even if it successfully ran for the amount of time specified by AppThrottle. NSSM will consult the REG_DWORD value at HKLM\SYSTEM\CurrentControlSet\Services\Parameters\AppRestartDelay for the number of milliseconds to wait before attempting a restart. If AppRestartDelay is set and the application is determined to be subject to throttling, NSSM will pause the service for whichever is longer of the configured restart delay and the calculated throttle period.
If AppRestartDelay is missing or invalid, only throttling will be applied.
NSSM will look in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Parameters\AppExit for string (REG_EXPAND_SZ) values corresponding to the exit code of the application. If the application exited with code 1, for instance, NSSM will look for a string value under AppExit called "1" or, if it does not find it, will fall back to the AppExit (Default) value. You can find out the exit code for the application by consulting the system event log. NSSM will log the exit code when the application exits.
Based on the data found in the registry, NSSM will take one of three actions:
If the value data is "Restart" NSSM will try to restart the application as described above. This is its default behaviour.
If the value data is "Ignore" NSSM will not try to restart the application but will continue running itself. This emulates the (usually undesirable) behaviour of srvany. The Windows Services console would show the service as still running even though the application has exited.
If the value data is "Exit" NSSM will exit gracefully. The Windows Services console would show the service as stopped. If you wish to provide finer-grained control over service recovery you should use this code and edit the failure action manually. Please note that Windows versions prior to Vista will not consider such an exit to be a failure. On older versions of Windows you should use "Suicide" instead.
If the value data is "Suicide" NSSM will simulate a crash and exit without informing the service manager. This option should only be used for pre-Vista systems where you wish to apply a service recovery action. Note that if the monitored application exits with code 0, NSSM will only honour a request to suicide if you explicitly configure a registry key for exit code 0. If only the default action is set to Suicide NSSM will instead exit gracefully.
NSSM can set the priority class of the managed application. NSSM will look in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Parameters for the REG_DWORD entry AppPriority. Valid values correspond to arguments to SetPriorityClass(). If AppPriority() is missing or invalid the application will be launched with normal priority.
NSSM can set the CPU affinity of the managed application. NSSM will look in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Parameters for the REG_SZ entry AppAffinity. It should specify a comma-separated listed of zero-indexed processor IDs. A range of processors may optionally be specified with a dash. No other characters are allowed in the string.
For example, to specify the first; second; third and fifth CPUs, an appropriate AppAffinity would be 0-2,4.
If AppAffinity is missing or invalid, NSSM will not attempt to restrict the application to specific CPUs.
Note that the 64-bit version of NSSM can configure a maximum of 64 CPUs in this way and that the 32-bit version can configure a maxium of 32 CPUs even when running on 64-bit Windows.
When stopping a service NSSM will attempt several different methods of killing the monitored application, each of which can be disabled if necessary.
First NSSM will attempt to generate a Control-C event and send it to the application's console. Batch scripts or console applications may intercept the event and shut themselves down gracefully. GUI applications do not have consoles and will not respond to this method.
Secondly NSSM will enumerate all windows created by the application and send them a WM_CLOSE message, requesting a graceful exit.
Thirdly NSSM will enumerate all threads created by the application and send them a WM_QUIT message, requesting a graceful exit. Not all applications' threads have message queues; those which do not will not respond to this method.
Finally NSSM will call TerminateProcess() to request that the operating system forcibly terminate the application. TerminateProcess() cannot be trapped or ignored, so in most circumstances the application will be killed. However, there is no guarantee that it will have a chance to perform any tidyup operations before it exits.
Any or all of the methods above may be disabled. NSSM will look for the HKLM\SYSTEM\CurrentControlSet\Services\Parameters\AppStopMethodSkip registry value which should be of type REG_DWORD set to a bit field describing which methods should not be applied.
If AppStopMethodSkip includes 1, Control-C events will not be generated. If AppStopMethodSkip includes 2, WM_CLOSE messages will not be posted. If AppStopMethodSkip includes 4, WM_QUIT messages will not be posted. If AppStopMethodSkip includes 8, TerminateProcess() will not be called.
If, for example, you knew that an application did not respond to Control-C events and did not have a thread message queue, you could set AppStopMethodSkip to 5 and NSSM would not attempt to use those methods to stop the application.
Take great care when including 8 in the value of AppStopMethodSkip. If NSSM does not call TerminateProcess() it is possible that the application will not exit when the service stops.
By default NSSM will allow processes 1500ms to respond to each of the methods described above before proceeding to the next one. The timeout can be configured on a per-method basis by creating REG_DWORD entries in the registry under HKLM\SYSTEM\CurrentControlSet\Services\Parameters.
AppStopMethodConsole AppStopMethodWindow AppStopMethodThreads
Each value should be set to the number of milliseconds to wait. Please note that the timeout applies to each process in the application's process tree, so the actual time to shutdown may be longer than the sum of all configured timeouts if the application spawns multiple subprocesses.
To skip applying the above stop methods to all processes in the application's process tree, applying them only to the original application process, set the HKLM\SYSTEM\CurrentControlSet\Services\Parameters\AppKillProcessTree registry value, which should be of type REG_DWORD, to 0.
No open issues yet, or sync has not completed.