| 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. | |
| Usage | |
| ----- | |
| In the usage notes below, arguments to the program may be written in angle | |
| brackets and/or square brackets. <string> means you must insert the | |
| appropriate string and [<string>] means the string is optional. See the | |
| examples below... | |
| Note that everywhere <servicename> appears you may substitute the | |
| service's display name. | |
| Installation using the GUI | |
| -------------------------- | |
| To install a service, run | |
| nssm install <servicename> | |
| 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... | |
| Installation using the command line | |
| ----------------------------------- | |
| To install a service, run | |
| nssm install <servicename> <application> [<options>] | |
| 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. | |
| Managing the service | |
| -------------------- | |
| 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\<service>\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\<service>\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\<service>\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. | |
| Application priority | |
| -------------------- | |
| NSSM can set the priority class of the managed application. NSSM will look in | |
| the registry under HKLM\SYSTEM\CurrentControlSet\Services\<service>\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. | |
| Processor affinity | |
| ------------------ | |
| NSSM can set the CPU affinity of the managed application. NSSM will look in | |
| the registry under HKLM\SYSTEM\CurrentControlSet\Services\<service>\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. | |
| Stopping the service | |
| -------------------- | |
| 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\<service>\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\<service>\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. | |
| Console window | |
| -------------- | |
| By default, NSSM will create a console window so that applications which | |
| are capable of reading user input can do so - subject to the service being | |
| allowed to interact with the desktop. | |
| Creation of the console can be suppressed by setting the integer (REG_DWORD) | |
| HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppNoConsole | |
| registry value to 1. | |
| I/O redirection | |
| --------------- | |
| NSSM can redirect the managed application's I/O to any path capable of being | |
| opened by CreateFile(). This enables, for example, capturing the log output | |
| of an application which would otherwise only write to the console or accepting | |
| input from a serial port. | |
| NSSM will look in the registry under | |
| HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters for the keys | |
| corresponding to arguments to CreateFile(). All are optional. If no path is | |
| given for a particular stream it will not be redirected. If a path is given | |
| but any of the other values are omitted they will be receive sensible defaults. | |
| AppStdin: Path to receive input. | |
| AppStdout: Path to receive output. | |
| AppStderr: Path to receive error output. | |
| Parameters for CreateFile() are providing with the "AppStdinShareMode", | |
| "AppStdinCreationDisposition" and "AppStdinFlagsAndAttributes" values (and | |
| analogously for stdout and stderr). | |
| In general, if you want the service to log its output, set AppStdout and | |
| AppStderr to the same path, eg C:\Users\Public\service.log, and it should | |
| work. Remember, however, that the path must be accessible to the user | |
| running the service. | |
| File rotation | |
| ------------- | |
| When using I/O redirection, NSSM can rotate existing output files prior to | |
| opening stdout and/or stderr. An existing file will be renamed with a | |
| suffix based on the file's last write time, to millisecond precision. For | |
| example, the file nssm.log might be rotated to nssm-20131221T113939.457.log. | |
| NSSM will look in the registry under | |
| HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters for REG_DWORD | |
| entries which control how rotation happens. | |
| If AppRotateFiles is missing or set to 0, rotation is disabled. Any non-zero | |
| value enables rotation. | |
| If AppRotateSeconds is non-zero, a file will not be rotated if its last write | |
| time is less than the given number of seconds in the past. | |
| If AppRotateBytes is non-zero, a file will not be rotated if it is smaller | |
| than the given number of bytes. 64-bit file sizes can be handled by setting | |
| a non-zero value of AppRotateBytesHigh. | |
| Rotation is independent of the CreateFile() parameters used to open the files. | |
| They will be rotated regardless of whether NSSM would otherwise have appended | |
| or replaced them. | |
| NSSM can also rotate files which hit the configured size threshold while the | |
| service is running. Additionally, you can trigger an on-demand rotation by | |
| running the command | |
| nssm rotate <servicename> | |
| On-demand rotations will happen after the next line of data is read from | |
| the managed application, regardless of the value of AppRotateBytes. Be aware | |
| that if the application is not particularly verbose the rotation may not | |
| happen for some time. | |
| To enable online and on-demand rotation, set AppRotateOnline to a non-zero | |
| value. | |
| Note that online rotation requires NSSM to intercept the application's I/O | |
| and create the output files on its behalf. This is more complex and | |
| error-prone than simply redirecting the I/O streams before launching the | |
| application. Therefore online rotation is not enabled by default. | |
| Environment variables | |
| --------------------- | |
| NSSM can replace or append to the managed application's environment. Two | |
| multi-valued string (REG_MULTI_SZ) registry values are recognised under | |
| HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters. | |
| AppEnvironment defines a list of environment variables which will override | |
| the service's environment. AppEnvironmentExtra defines a list of | |
| environment variables which will be added to the service's environment. | |
| Each entry in the list should be of the form KEY=VALUE. It is possible to | |
| omit the VALUE but the = symbol is mandatory. | |
| Environment variables listed in both AppEnvironment and AppEnvironmentExtra | |
| are subject to normal expansion, so it is possible, for example, to update the | |
| system path by setting "PATH=C:\bin;%PATH%" in AppEnvironmentExtra. Variables | |
| are expanded in the order in which they appear, so if you want to include the | |
| value of one variable in another variable you should declare the dependency | |
| first. | |
| Because variables defined in AppEnvironment override the existing | |
| environment it is not possible to refer to any variables which were previously | |
| defined. | |
| For example, the following AppEnvironment block: | |
| PATH=C:\Windows\System32;C:\Windows | |
| PATH=C:\bin;%PATH% | |
| Would result in a PATH of "C:\bin;C:\Windows\System32;C:\Windows" as expected. | |
| Whereas the following AppEnvironment block: | |
| PATH=C:\bin;%PATH% | |
| Would result in a path containing only C:\bin and probably cause the | |
| application to fail to start. | |
| Most people will want to use AppEnvironmentExtra exclusively. srvany only | |
| supports AppEnvironment. | |
| Managing services using the GUI | |
| ------------------------------- | |
| NSSM can edit the settings of existing services with the same GUI that is | |
| used to install them. Run | |
| nssm edit <servicename> | |
| to bring up the GUI. | |
| NSSM offers limited editing capabilities for services other than those which | |
| run NSSM itself. When NSSM is asked to edit a service which does not have | |
| the App* registry settings described above, the GUI will allow editing only | |
| system settings such as the service display name and description. | |
| Managing services using the command line | |
| ---------------------------------------- | |
| NSSM can retrieve or set individual service parameters from the command line. | |
| In general the syntax is as follows, though see below for exceptions. | |
| nssm get <servicename> <parameter> | |
| nssm set <servicename> <parameter> <value> | |
| Parameters can also be reset to their default values. | |
| nssm reset <servicename> <parameter> | |
| The parameter names recognised by NSSM are the same as the registry entry | |
| names described above, eg AppDirectory. | |
| NSSM offers limited editing capabilities for Services other than those which | |
| run NSSM itself. The parameters recognised are as follows: | |
| Description: Service description. | |
| DisplayName: Service display name. | |
| ImagePath: Path to the service executable. | |
| ObjectName: User account which runs the service. | |
| Name: Service key name. | |
| Start: Service startup type. | |
| Type: Service type. | |
| These correspond to the registry values under the service's key | |
| HKLM\SYSTEM\CurrentControlSet\Services\<service>. | |
| Note that NSSM will concatenate all arguments passed on the command line | |
| with spaces to form the value to set. Thus the following two invocations | |
| would have the same effect. | |
| nssm set <servicename> Description "NSSM managed service" | |
| nssm set <servicename> Description NSSM managed service | |
| Non-standard parameters | |
| ----------------------- | |
| The AppEnvironment and AppEnvironmentExtra parameters recognise an | |
| additional argument when querying the environment. The following syntax | |
| will print all extra environment variables configured for a service | |
| nssm get <servicename> AppEnvironmentExtra | |
| whereas the syntax below will print only the value of the CLASSPATH | |
| variable if it is configured in the environment block, or the empty string | |
| if it is not configured. | |
| nssm get <servicename> AppEnvironmentExtra CLASSPATH | |
| When setting an environment block, each variable should be specified as a | |
| KEY=VALUE pair in separate command line arguments. For example: | |
| nssm set <servicename> AppEnvironment CLASSPATH=C:\Classes TEMP=C:\Temp | |
| The AppExit parameter requires an additional argument specifying the exit | |
| code to get or set. The default action can be specified with the string | |
| Default. | |
| For example, to get the default exit action for a service you should run | |
| nssm get <servicename> AppExit Default | |
| To get the exit action when the application exits with exit code 2, run | |
| nssm get <servicename> AppExit 2 | |
| Note that if no explicit action is configured for a specified exit code, | |
| NSSM will print the default exit action. | |
| To set configure the service to stop when the application exits with an | |
| exit code of 2, run | |
| nssm set <servicename> AppExit 2 Exit | |
| The AppPriority parameter is used to set the priority class of the | |
| managed application. Valid priorities are as follows: | |
| REALTIME_PRIORITY_CLASS | |
| HIGH_PRIORITY_CLASS | |
| ABOVE_NORMAL_PRIORITY_CLASS | |
| NORMAL_PRIORITY_CLASS | |
| BELOW_NORMAL_PRIORITY_CLASS | |
| IDLE_PRIORITY_CLASS | |
| The DependOnGroup and DependOnService parameters are used to query or set | |
| the dependencies for the service. When setting dependencies, each service | |
| or service group (preceded with the + symbol) should be specified in | |
| separate command line arguments. For example: | |
| nssm set <servicename> DependOnService RpcSs LanmanWorkstation | |
| The Name parameter can only be queried, not set. It returns the service's | |
| registry key name. This may be useful to know if you take advantage of | |
| the fact that you can substitute the service's display name anywhere where | |
| the syntax calls for <servicename>. | |
| The ObjectName parameter requires an additional argument only when setting | |
| a username. The additional argument is the password of the user. | |
| To retrieve the username, run | |
| nssm get <servicename> ObjectName | |
| To set the username and password, run | |
| nssm set <servicename> ObjectName <username> <password> | |
| Note that the rules of argument concatenation still apply. The following | |
| invocation is valid and will have the expected effect. | |
| nssm set <servicename> ObjectName <username> correct horse battery staple | |
| The following well-known usernames do not need a password. The password | |
| parameter can be omitted when using them: | |
| "LocalSystem" aka "System" aka "NT Authority\System" | |
| "LocalService" aka "Local Service" aka "NT Authority\Local Service" | |
| "NetworkService" aka "Network Service" aka "NT Authority\Network Service" | |
| The Start parameter is used to query or set the startup type of the service. | |
| Valid service startup types are as follows: | |
| SERVICE_AUTO_START: Automatic startup at boot. | |
| SERVICE_DELAYED_START: Delayed startup at boot. | |
| SERVICE_DEMAND_START: Manual service startup. | |
| SERVICE_DISABLED: The service is disabled. | |
| Note that SERVICE_DELAYED_START is not supported on versions of Windows prior | |
| to Vista. NSSM will set the service to automatic startup if delayed start is | |
| unavailable. | |
| The Type parameter is used to query or set the service type. NSSM recognises | |
| all currently documented service types but will only allow setting one of two | |
| types: | |
| SERVICE_WIN32_OWN_PROCESS: A standalone service. This is the default. | |
| SERVICE_INTERACTIVE_PROCESS: A service which can interact with the desktop. | |
| Note that a service may only be configured as interactive if it runs under | |
| the LocalSystem account. The safe way to configure an interactive service | |
| is in two stages as follows. | |
| nssm reset <servicename> ObjectName | |
| nssm set <servicename> Type SERVICE_INTERACTIVE_PROCESS | |
| Controlling services using the command line | |
| ------------------------------------------- | |
| NSSM offers rudimentary service control features. | |
| nssm start <servicename> | |
| nssm restart <servicename> | |
| nssm stop <servicename> | |
| nssm status <servicename> | |
| Removing services using the GUI | |
| ------------------------------- | |
| NSSM can also remove services. Run | |
| nssm remove <servicename> | |
| to remove a service. You will prompted for confirmation before the service | |
| is removed. Try not to remove essential system services... | |
| Removing service using the command line | |
| --------------------------------------- | |
| To remove a service without confirmation from the GUI, run | |
| nssm remove <servicename> confirm | |
| Try not to remove essential system services... | |
| Logging | |
| ------- | |
| NSSM logs to the Windows event log. It registers itself as an event log source | |
| and uses unique event IDs for each type of message it logs. New versions may | |
| add event types but existing event IDs will never be changed. | |
| Because of the way NSSM registers itself you should be aware that you may not | |
| be able to replace the NSSM binary if you have the event viewer open and that | |
| running multiple instances of NSSM from different locations may be confusing if | |
| they are not all the same version. | |
| Example usage | |
| ------------- | |
| To install an Unreal Tournament server: | |
| nssm install UT2004 c:\games\ut2004\system\ucc.exe server | |
| To run the server as the "games" user: | |
| nssm set UT2004 ObjectName games password | |
| To configure the server to log to a file: | |
| nssm set UT2004 AppStdout c:\games\ut2004\service.log | |
| To restrict the server to a single CPU: | |
| nssm set UT2004 AppAffinity 0 | |
| To remove the server: | |
| nssm remove UT2004 confirm | |
| To find out the service name of a service with a display name: | |
| nssm get "Background Intelligent Transfer Service" Name | |
| Building NSSM from source | |
| ------------------------- | |
| NSSM is known to compile with Visual Studio 2008 and later. Older Visual | |
| Studio releases may or may not work if you install an appropriate SDK and | |
| edit the nssm.vcproj and nssm.sln files to set a lower version number. | |
| They are known not to work with default settings. | |
| NSSM will also compile with Visual Studio 2010 but the resulting executable | |
| will not run on versions of Windows older than XP SP2. If you require | |
| compatiblity with older Windows releases you should change the Platform | |
| Toolset to v90 in the General section of the project's Configuration | |
| Properties. | |
| Credits | |
| ------- | |
| Thanks to Bernard Loh for finding a bug with service recovery. | |
| Thanks to Benjamin Mayrargue (www.softlion.com) for adding 64-bit support. | |
| Thanks to Joel Reingold for spotting a command line truncation bug. | |
| Thanks to Arve Knudsen for spotting that child processes of the monitored | |
| application could be left running on service shutdown, and that a missing | |
| registry value for AppDirectory confused NSSM. | |
| Thanks to Peter Wagemans and Laszlo Keresztfalvi for suggesting throttling | |
| restarts. | |
| Thanks to Eugene Lifshitz for finding an edge case in CreateProcess() and for | |
| advising how to build messages.mc correctly in paths containing spaces. | |
| Thanks to Rob Sharp for pointing out that NSSM did not respect the | |
| AppEnvironment registry value used by srvany. | |
| Thanks to Szymon Nowak for help with Windows 2000 compatibility. | |
| Thanks to François-Régis Tardy and Gildas le Nadan for French translation. | |
| Thanks to Emilio Frini for spotting that French was inadvertently set as | |
| the default language when the user's display language was not translated. | |
| Thanks to Riccardo Gusmeroli and Marco Certelli for Italian translation. | |
| Thanks to Eric Cheldelin for the inspiration to generate a Control-C event | |
| on shutdown. | |
| Thanks to Brian Baxter for suggesting how to escape quotes from the command | |
| prompt. | |
| Thanks to Russ Holmann for suggesting that the shutdown timeout be configurable. | |
| Thanks to Paul Spause for spotting a bug with default registry entries. | |
| Thanks to BUGHUNTER for spotting more GUI bugs. | |
| Thanks to Doug Watson for suggesting file rotation. | |
| Thanks to Арслан Сайдуганов for suggesting setting process priority. | |
| Thanks to Robert Middleton for suggestion and draft implementation of process | |
| affinity support. | |
| Thanks to Andrew RedzMax for suggesting an unconditional restart delay. | |
| Thanks to Bryan Senseman for noticing that applications with redirected stdout | |
| and/or stderr which attempt to read from stdin would fail. | |
| Thanks to Czenda Czendov for help with Visual Studio 2013 and Server 2012R2. | |
| Thanks to Alessandro Gherardi for reporting and draft fix of the bug whereby | |
| the second restart of the application would have a corrupted environment. | |
| Thanks to Hadrien Kohl for suggesting to disable the console window's menu. | |
| Thanks to Allen Vailliencourt for noticing bugs with configuring the service to | |
| run under a local user account. | |
| Thanks to Sam Townsend for noticing a regression with TerminateProcess(). | |
| Licence | |
| ------- | |
| NSSM is public domain. You may unconditionally use it and/or its source code | |
| for any purpose you wish. | |