NSSM: Управление службами без сбоев
Версия 2.24, 2014-08-31

NSSM — это программа-помощник для служб, похожая на srvany и cygrunsrv. Она может запускать любое приложение как службу Windows и перезапускать службу, если она завершается по любой причине.

NSSM также имеет графический инсталлятор и удалятор служб.

Полная документация доступна онлайн по адресу

                              http://nssm.cc/

С версии 2.0 графический интерфейс можно обойти, введя все необходимые параметры на командной строке.

С версии 2.1 NSSM может компилироваться для платформ x64.
Спасибо Benjamin Mayrargue.

С версии 2.2 NSSM может быть настроен для выполнения различных действий в зависимости от кода завершения управляемого приложения.

С версии 2.3 NSSM ведет журналы в Windows Event Log более элегантно.

С версии 2.5 NSSM учитывает переменные окружения в своих параметрах.

С версии 2.8 NSSM старается более тщательно останавливать управляемое приложение и ограничивает попытки перезапуска, если приложение не работает достаточное время.

С версии 2.11 NSSM учитывает параметр AppEnvironment от srvany.

С версии 2.13 NSSM переведен на французский язык.
Спасибо François-Régis Tardy.

С версии 2.15 NSSM переведен на итальянский язык.
Спасибо Riccardo Gusmeroli.

С версии 2.17 NSSM может попытаться остановить консольные приложения, имитируя нажатие клавиши Control-C. Если они установили обработчик событий, они могут очиститься и остановиться грациозно при получении события.С версии 2.17 NSSM может перенаправлять потоки ввода-вывода управляемого приложения на произвольный путь.

С версии 2.18 NSSM может быть настроен для ожидания пользовательского времени перед завершением приложения.

С версии 2.19 многие параметры службы могут быть настроены с помощью графического инсталлятора, а также через реестр.

С версии 2.19 NSSM может добавлять к окружению службы, устанавливая AppEnvironmentExtra вместо или в дополнение к srvany-совместимому AppEnvironment.

С версии 2.22 NSSM может устанавливать приоритет процесса управляемого приложения и аффинность процессора.

С версии 2.22 NSSM может применять безусловную задержку перед перезапуском приложения, завершившего работу.

С версии 2.22 NSSM может перезаписывать существующие файлы вывода при перенаправлении ввода-вывода. С версии 2.22 NSSM может устанавливать отображаемое имя службы, описание, тип запуска, сведения о входе и зависимости.

С версии 2.22 NSSM может управлять существующими службами.


Использование
-----
В заметках ниже по использованию аргументы программы могут быть записаны в угловых и/или квадратных скобках. <string> означает, что вам нужно вставить соответствующую строку, а [<string>] означает, что строка является необязательной. См. примеры ниже...

Обратите внимание, что везде, где появляется <servicename>, вы можете заменить его отображаемым именем службы.Установка с помощью графического интерфейса
--------------------------
Чтобы установить службу, выполните

    nssm install <servicename>

Вам будет предложено ввести полный путь к приложению, которое вы хотите запустить, и любые параметры командной строки для передачи этому приложению.

Используйте системный менеджер служб (services.msc), чтобы контролировать продвинутые свойства службы, такие как метод запуска и взаимодействие с рабочим столом. NSSM может поддерживать эти опции в будущем...


Установка с помощью командной строки
-----------------------------------
Чтобы установить службу, выполните

    nssm install <servicename> <application> [<options>]

NSSM попытается установить службу, которая запускает указанное приложение с указанными параметрами (если вы их указали).

Не забудьте заключать пути в "кавычки", если они содержат пробелы!

Если вы хотите включить кавычки в параметры, вам потребуется """заключить кавычки в кавычки""".


Управление службой
--------------------
NSSM запускает приложение, указанное в реестре, когда вы отправляете ему сигнал запуска, и завершает его, когда вы отправляете сигнал завершения. В этом смысле NSSM похож на srvany. Но NSSM — это Непьющий менеджер служб и может предпринять действия, если/когда приложение прекращает работу.Без какого-либо конфигурирования со стороны пользователя NSSM попытается перезапустить себя, если заметит, что приложение прекратило работу, но вы не отправили ему сигнал завершения. NSSM будет продолжать пытаться, делая паузы между каждым попыткой, до тех пор, пока служба не будет успешно запущена или вы не отправите ему сигнал завершения.NSSM будет делать все более длительные паузы между последовательными попытками перезапуска, если служба не запускается вовремя, до максимального времени 4 минуты. Это сделано для того, чтобы не расходовать избыточное количество времени процессора на попытки запуска неудачного приложения снова и снова. Если вы определите причину неудачи и не хотите ждать, вы можете использовать консоль Windows служб (где служба будет показана в состоянии "Приостановлено"), чтобы отправить сигнал продолжения NSSM, и он попытается перезапуститься в течение нескольких секунд. По умолчанию, NSSM определяет "в разумный срок" как 1500 миллисекунд.

Вы можете изменить порог для сервиса, установив количество миллисекунд как значение REG_DWORD в реестре по адресу
HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppThrottle.

В качестве альтернативы, NSSM может приостановить выполнение на настраиваемое количество времени перед попыткой перезапуска приложения, даже если оно успешно запустилось за время, указанное в AppThrottle. NSSM будет проверять значение REG_DWORD по адресу HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppRestartDelay для количества миллисекунд, которые нужно подождать перед попыткой перезапуска. Если AppRestartDelay установлен и приложение определено как подлежащее ограничению, NSSM приостановит сервис на более длительное время из двух: настроенный перезапуск и рассчитанный период ограничения.Если параметр **AppRestartDelay** отсутствует или недействителен, применяется только ограничение.

NSSM будет искать в реестре по адресу
**HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppExit** для строковых (REG_EXPAND_SZ) значений, соответствующих коду выхода приложения. Если приложение завершило работу с кодом 1, например, NSSM будет искать строковое значение под названием "1" в **AppExit** или, если оно не найдено, вернется к значению **AppExit (Default)**. Вы можете узнать код выхода приложения, проверив системный журнал событий. NSSM будет регистрировать код выхода приложения при его завершении работы.

На основе данных, найденных в реестре, NSSM будет выполнять одно из трех действий:

Если значение данных равно "Restart", NSSM попытается перезапустить приложение, как описано выше. Это его стандартное поведение.

Если значение данных равно "Ignore", NSSM не попытается перезапустить приложение, но продолжит свое выполнение. Это имитирует (обычно нежелательное) поведение srvany. Консоль управления службами Windows покажет службу как работающую, даже если приложение завершило работу.Если значение данных равно "Exit", NSSM завершит работу грациозно. Консоль управления службами Windows покажет службу как остановленную. Если вы хотите предоставить более тонкое управление восстановлением службы, вы должны использовать этот код и редактировать действие ошибки вручную. Пожалуйста, обратите внимание, что версии Windows до Vista не будут считать такой выход ошибкой. На более старых версиях Windows вы должны использовать "Suicide" вместо.

Если значение данных равно "Suicide", NSSM будет имитировать аварийное завершение и выйдет, не уведомляя управляющего сервиса. Эта опция должна использоваться только для систем до Vista, где вы хотите применить действие восстановления сервиса. Обратите внимание, что если отслеживаемое приложение завершается с кодом 0, NSSM будет уважать запрос на аварийное завершение только в том случае, если вы явно настроите ключ реестра для кода завершения 0. Если только по умолчанию действие настроено на Suicide, NSSM вместо этого завершит работу грациозно.Приоритет приложения
--------------------
NSSM может установить класс приоритета управляемого приложения. NSSM будет искать в реестре в HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters за записью REG_DWORD AppPriority. Допустимые значения соответствуют аргументам функции SetPriorityClass(). Если AppPriority отсутствует или недействителен, приложение будет запущено с нормальным приоритетом.

Процессорная привязка
----------------------
NSSM может установить привязку процессора для управляемого приложения. NSSM будет искать в реестре в HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters за записью REG_SZ AppAffinity. Она должна указывать запятой-разделенный список нумерованных с нуля идентификаторов процессоров. Диапазон процессоров может быть указан с помощью тире. В строке не должны присутствовать другие символы.

Например, чтобы указать первый, второй, третий и пятый процессоры, подходящее значение AppAffinity будет 0,1,2,4.

Если AppAffinity отсутствует или недействителен, NSSM не попытается ограничить приложение определенными процессорами.

Обратите внимание, что 64-битная версия NSSM может настроить максимум 64 процессора таким образом, а 32-битная версия может настроить максимум 32 процессора даже при работе на 64-битной версии Windows.

Остановка сервиса
-----------------
При остановке сервиса NSSM попытается использовать несколько различных методов для завершения отслеживаемого приложения, каждый из которых может быть отключен, если это необходимо.Сначала NSSM попытается сгенерировать событие Control-C и отправить его в консоль приложения. Скрипты командной строки или консольные приложения могут перехватить это событие и грациозно завершить работу. Приложения с графическим интерфейсом не имеют консоли и не отвечают на этот метод.

Во-вторых NSSM перечислит все окна, созданные приложением, и отправит им сообщение WM_CLOSE, запрашивая грациозное завершение работы. Третьим шагом NSSM перечислит все потоки, созданные приложением, и отправит им сообщение WM_QUIT, запрашивая грациозное завершение работы. Не все потоки приложений имеют очереди сообщений; те, у которых их нет, не отвечают на этот метод.

Наконец, NSSM вызывает функцию TerminateProcess(), чтобы запросить операционную систему принудительно завершить приложение. Функция TerminateProcess() не может быть перехвачена или проигнорирована, поэтому в большинстве случаев приложение будет завершено. Однако нет гарантии, что оно получит возможность выполнить какие-либо операции по уборке перед завершением.

Любой или все из вышеупомянутых методов могут быть отключены. NSSM ищет значение параметра registry HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppStopMethodSkip, которое должно быть типа REG_DWORD и установлено в поле битов, описывающее, какие методы не следует применять.  Если AppStopMethodSkip включает 1, события Control-C не будут генерироваться.
  Если AppStopMethodSkip включает 2, сообщения WM_CLOSE не будут отправлены.
  Если AppStopMethodSkip включает 4, сообщения WM_QUIT не будут отправлены.
  Если AppStopMethodSkip включает 8, функция TerminateProcess() не будет вызвана.

Например, если вы знаете, что приложение не отвечает на события Control-C и не имеет очереди сообщений потока, вы можете установить AppStopMethodSkip на 5, и NSSM не попытается использовать эти методы для остановки приложения.

Будьте очень осторожны при включении 8 в значение AppStopMethodSkip. Если NSSM не вызывает функцию TerminateProcess(), возможно, что приложение не завершится при остановке службы.

По умолчанию NSSM позволяет процессам 1500 миллисекунд на ответ на каждый из вышеупомянутых методов перед переходом к следующему. Время ожидания может быть настроено для каждого метода отдельно путем создания параметров REG_DWORD в реестре под HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters.

  AppStopMethodConsole
  AppStopMethodWindow
  AppStopMethodThreads

Каждое значение должно быть установлено в количество миллисекунд для ожидания. Пожалуйста, обратите внимание, что время ожидания применяется к каждому процессу в дереве процессов приложения, поэтому фактическое время для завершения может быть больше, чем сумма всех настроенных значений времени ожидания, если приложение запускает несколько подпроцессов.Консольное окно
----------------
По умолчанию NSSM создает консольное окно, чтобы приложения, способные читать пользовательский ввод, могли это делать — при условии, что служба разрешена для взаимодействия с рабочим столом. Создание консоли может быть отключено путем установки целого числа (REG_DWORD) в реестре HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters\AppNoConsole значение в 1.


Перенаправление ввода-вывода
----------------------------
NSSM может перенаправлять ввод и вывод управляемого приложения на любой путь, доступный для открытия с помощью CreateFile(). Это позволяет, например, захватывать выходные данные журнала приложения, которое в противном случае записывалось бы только в консоль, или принимать ввод с последовательного порта.

NSSM будет искать соответствующие ключи аргументов CreateFile() в реестре под HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters. Все ключи являются необязательными. Если для определенного потока не указан путь, перенаправление не будет выполнено. Если указан путь, но отсутствуют другие значения, они будут получать разумные значения по умолчанию.

  AppStdin: Путь для получения ввода.
  AppStdout: Путь для получения вывода.
  AppStderr: Путь для получения вывода ошибок.

Параметры для CreateFile() предоставляются значениями "AppStdinShareMode", "AppStdinCreationDisposition" и "AppStdinFlagsAndAttributes" (и аналогично для stdout и stderr).В общем случае, если вы хотите, чтобы служба записывала свои выходные данные в журнал, установите AppStdout и AppStderr на один и тот же путь, например C:\Users\Public\service.log, и это должно работать. Однако помните, что путь должен быть доступен пользователю, запускающему службу.


Вращение файлов
---------------
При использовании перенаправления ввода-вывода NSSM может вращать существующие файлы вывода перед открытием stdout и/или stderr. Существующий файл будет переименован с помощью суффикса, основанного на последнем времени записи файла, с точностью до миллисекунд. Например, файл nssm.log может быть вращен в nssm-20131221T113939.457.log.

NSSM будет искать REG_DWORD записи в реестре под
HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters, которые контролируют процесс вращения файлов.

Если AppRotateFiles отсутствует или установлено в 0, вращение отключено. Любое ненулевое значение включает вращение.

Если AppRotateSeconds не равно 0, файл не будет вращен, если его последнее время записи было меньше указанного числа секунд в прошлом.

Если AppRotateBytes не равно 0, файл не будет вращен, если он меньше указанного числа байт. 64-битные размеры файлов могут быть обработаны путем установки ненулевого значения AppRotateBytesHigh. Вращение независимо от параметров CreateFile(), используемых для открытия файлов. Они будут вращаться независимо от того, добавлял ли бы NSSM к ним что-либо или заменял.NSSM также может выполнять поворот файлов, которые достигли настроенных порогов размера во время работы службы. 
Кроме того, вы можете запустить поворот по требованию, выполнив команду

    nssm rotate <servicename>

Поворот по требованию произойдет после следующей строки данных, прочитанной из управляемого приложения, независимо от значения AppRotateBytes. Будьте внимательны к тому, что если приложение не очень разговорчивое, поворот может не произойти в течение некоторого времени.

Чтобы включить поворот в режиме онлайн и по требованию, установите AppRotateOnline в ненулевое значение.

Обратите внимание, что поворот в режиме онлайн требует от NSSM перехвата ввода-вывода приложения и создания выходных файлов от его имени. Это более сложная и ошибочная процедура, чем просто перенаправление потоков ввода-вывода перед запуском приложения. Поэтому поворот в режиме онлайн по умолчанию не включен.


Переменные окружения
---------------------
NSSM может заменять или дополнять окружение управляемого приложения. Два многострочных значения (REG_MULTI_SZ) в реестре признаны под HKLM\SYSTEM\CurrentControlSet\Services\<service>\Parameters.

AppEnvironment определяет список переменных окружения, которые будут переопределять окружение службы. AppEnvironmentExtra определяет список переменных окружения, которые будут добавлены в окружение службы.Каждый элемент в списке должен быть в формате KEY=VALUE. Возможно, опустить VALUE, но символ = обязателен.

Переменные окружения, перечисленные в AppEnvironment и AppEnvironmentExtra, подлежат обычному расширению, поэтому, например, можно обновить системный путь, установив "PATH=C:\bin;%PATH%" в AppEnvironmentExtra. Переменные расширяются в порядке их появления, поэтому если вы хотите включить значение одной переменной в другую, вы должны объявить зависимость первой.

Поскольку переменные, определенные в AppEnvironment, переопределяют существующее окружение, невозможно ссылаться на переменные, которые были определены ранее.

Например, следующий блок AppEnvironment:

      PATH=C:\Windows\System32;C:\Windows
      PATH=C:\bin;%PATH%

Результатом будет PATH вида "C:\bin;C:\Windows\System32;C:\Windows", как ожидается.

В то время как следующий блок AppEnvironment:

      PATH=C:\bin;%PATH%

Результатом будет путь, содержащий только C:\bin, что, вероятно, вызовет неудачу при запуске приложения.

Большинство людей захотят использовать AppEnvironmentExtra исключительно. srvany поддерживает только AppEnvironment.


Управление службами с помощью графического интерфейса
-----------------------------------------------------
NSSM может редактировать параметры существующих служб с помощью того же графического интерфейса, который используется для их установки. Запустите

    nssm edit <servicename>

для отображения графического интерфейса.NSSM предлагает ограниченные возможности редактирования для служб, кроме тех, которые запускают NSSM сам. Когда NSSM запрашивает редактирование службы, которая не имеет параметров App* описанных выше, графический интерфейс позволит редактировать только системные параметры, такие как имя отображения службы и описание.

Управление службами с помощью командной строки
----------------------------------------------
NSSM может получать или устанавливать отдельные параметры службы с помощью командной строки. В общем синтаксис следующий, хотя см. ниже для исключений.

    nssm get <servicename> <parameter>

    nssm set <servicename> <parameter> <value>

Параметры также могут быть сброшены до значений по умолчанию.

    nssm reset <servicename> <parameter>

Имена параметров, распознаваемые NSSM, такие же, как имена записей реестра, описанных выше, например AppDirectory.

NSSM предлагает ограниченные возможности редактирования для служб, кроме тех, которые запускают NSSM сам. Распознаваемые параметры следующие:

  Description: Описание службы.
  DisplayName: Имя отображения службы.
  ImagePath: Путь к исполняемому файлу службы.
  ObjectName: Учетная запись пользователя, которая запускает службу.
  Name: Имя ключа службы.
  Start: Тип запуска службы.
  Type: Тип службы.

Эти параметры соответствуют значениям реестра под ключом службы
HKLM\SYSTEM\CurrentControlSet\Services\<service>.Обратите внимание, что NSSM будет объединять все аргументы, переданные через командную строку, с пробелами для формирования значения для установки. Таким образом, следующие два вызова будут иметь одинаковый эффект.

    nssm set <servicename> Description "NSSM управляемая служба"

    nssm set <servicename> Description NSSM управляемая служба

Нестандартные параметры
-----------------------
Параметры AppEnvironment и AppEnvironmentExtra распознают дополнительный аргумент при запросе окружения. Следующий синтаксис выведет все дополнительные переменные окружения, настроенные для службы:

    nssm get <имя_сервиса> AppEnvironmentExtra

в отличие от синтаксиса ниже, который выведет только значение переменной CLASSPATH, если она настроена в блоке окружения, или пустую строку, если она не настроена:

    nssm get <имя_сервиса> AppEnvironmentExtra CLASSPATH

При настройке блока окружения каждая переменная должна быть указана как пара ключ=значение в отдельных аргументах командной строки. Например:

    nssm set <имя_сервиса> AppEnvironment CLASSPATH=C:\Classes TEMP=C:\Temp

Параметр AppExit требует дополнительного аргумента, указывающего код выхода для получения или установки. Действие по умолчанию можно указать строкой Default.

Например, чтобы получить действие выхода по умолчанию для сервиса, следует выполнить:

    nssm get <имя_сервиса> AppExit Default

Чтобы получить действие выхода, когда приложение завершает работу с кодом выхода 2, выполните:

    nssm get <имя_сервиса> AppExit 2    nssm get <имя_сервиса> AppExit 2

Обратите внимание, что если для указанного кода выхода не настроено явное действие,
NSSM выведет действие выхода по умолчанию.

Чтобы настроить сервис так, чтобы он останавливался, когда приложение завершает работу с кодом выхода 2, выполните

    nssm set <имя_сервиса> AppExit 2 Exit

Параметр AppPriority используется для установки класса приоритета управляемого приложения.
Допустимые приоритеты следующие:

  REALTIME_PRIORITY_CLASS
  HIGH_PRIORITY_CLASS
  ABOVE_NORMAL_PRIORITY_CLASS
  NORMAL_PRIORITY_CLASS
  BELOW_NORMAL_PRIORITY_CLASS
  IDLE_PRIORITY_CLASS

Параметры DependOnGroup и DependOnService используются для запроса или установки зависимостей сервиса.
При настройке зависимостей каждая служба или группа служб (предшествующая символом +) должна быть указана в отдельных аргументах командной строки. Например:

    nssm set <имя_сервиса> DependOnService RpcSs LanmanWorkstation

Параметр Name можно только запросить, но не установить. Он возвращает имя ключа реестра сервиса.
Это может быть полезно знать, если вы воспользуетесь тем фактом, что вы можете заменить имя отображения сервиса в любом месте, где синтаксис требует <имя_сервиса>.

Параметр ObjectName требует дополнительного аргумента только при установке имени пользователя. Дополнительный аргумент — это пароль пользователя.

Чтобы получить имя пользователя, выполните

    nssm get <имя_сервиса> ObjectName    nssm get <имя_сервиса> ObjectName

Чтобы установить имя пользователя и пароль, выполните    nssm set <имя_сервиса> ObjectName <имя_пользователя> <пароль>

Обратите внимание, что правила конкатенации аргументов по-прежнему применяются.  Следующий
вызов является допустимым и будет иметь ожидаемый эффект.

    nssm set <имя_сервиса> ObjectName <имя_пользователя> правильный конь батарейный staples

Следующие хорошо известные имена пользователей не требуют пароля.  Параметр пароля
может быть опущен при использовании их:

  "LocalSystem" также известен как "System" также известен как "NT Authority\System"
  "LocalService" также известен как "Local Service" также известен как "NT Authority\Local Service"
  "NetworkService" также известен как "Network Service" также известен как "NT Authority\Network Service"

Параметр Start используется для запроса или установки типа запуска службы.
Допустимые типы запуска службы следующие:

  SERVICE_AUTO_START: Автоматический запуск при загрузке.
  SERVICE_DELAYED_START: Задержанный запуск при загрузке.
  SERVICE_DEMAND_START: Ручной запуск службы.
  SERVICE_DISABLED: Служба отключена.

Обратите внимание, что SERVICE_DELAYED_START не поддерживается в версиях Windows, предшествующих
Vista.  NSSM установит службу на автоматический запуск, если задержанный запуск недоступен.

Параметр Type используется для запроса или установки типа службы. NSSM распознает
все документированные типы служб, но позволит установить только один из двух типов:  SERVICE_WIN32_OWN_PROCESS: Отдельная служба. Это значение по умолчанию.
  SERVICE_INTERACTIVE_PROCESS: Служба, которая может взаимодействовать с рабочим столом.

Обратите внимание, что служба может быть настроена как интерактивная только если она запускается
под учетной записью LocalSystem. Безопасный способ настройки интерактивной службы
состоит из двух этапов следующим образом.

    nssm reset <имя_сервиса> ObjectName
    nssm set <имя_сервиса> Type SERVICE_INTERACTIVE_PROCESS


Управление службами с помощью командной строки
----------------------------------------------
NSSM предлагает базовые возможности управления службами.

    nssm start <имя_сервиса>

    nssm restart <имя_сервиса>

    nssm stop <имя_сервиса>

    nssm status <имя_сервиса>


Удаление служб с помощью графического интерфейса
-----------------------------------------------
NSSM также может удалять службы. Запустите

    nssm remove <имя_сервиса>

для удаления службы. Вас спросят подтверждение перед удалением службы. Постарайтесь не удалять
необходимые системные службы...


Удаление службы с помощью командной строки
-----------------------------------------
Чтобы удалить службу без подтверждения графического интерфейса, запустите

    nssm remove <имя_сервиса> confirm

Постарайтесь не удалять важные системные службы...Журналирование
--------------
NSSM записывает журналы в Windows event log. Он регистрирует себя как источник событий и использует уникальные идентификаторы событий для каждого типа сообщений, которые он записывает. Новые версии могут добавлять типы событий, но существующие идентификаторы событий никогда не будут изменены.Поскольку NSSM регистрирует себя определенным образом, вы должны знать, что при открытом окне просмотра событий Windows вам может быть невозможно заменить исполняемый файл NSSM. Кроме того, запуск нескольких экземпляров NSSM из разных мест может быть запутанным, если они не являются одной и той же версией.


Пример использования
--------------------
Чтобы установить сервер Unreal Tournament:

    nssm install UT2004 c:\games\ut2004\system\ucc.exe server

Чтобы запустить сервер под пользователем "games":

    nssm set UT2004 ObjectName games password

Чтобы настроить сервер на запись в файл:

    nssm set UT2004 AppStdout c:\games\ut2004\service.log

Чтобы ограничить сервер одним процессором:

    nssm set UT2004 AppAffinity 0

Чтобы удалить сервер:

    nssm remove UT2004 confirm

Чтобы узнать имя службы по ее отображаемому имени:

    nssm get "Background Intelligent Transfer Service" Name


Сборка NSSM из исходного кода
-----------------------------
NSSM известен как компилируемый с Visual Studio 2008 и более поздних версий. Старые версии Visual Studio могут или могут не компилироваться, если вы установите соответствующий SDK и отредактируете файлы nssm.vcproj и nssm.sln для установки более ранней версии. Они известны тем, что не компилируются с настройками по умолчанию.NSSM также компилируется с Visual Studio 2010, но получившийся исполняемый файл не будет работать на версиях Windows старше XP SP2. Если вам требуется совместимость с более старыми версиями Windows, вы должны изменить Platform Toolset на v90 в разделе General конфигурационных свойств проекта.

Заслуги
-------
Спасибо Bernard Loh за обнаружение ошибки с восстановлением службы.
Спасибо Benjamin Mayrargue (www.softlion.com) за добавление поддержки bk-систем.
Спасибо Joel Reingold за обнаружение ошибки с обрезкой командной строки.
Спасибо Arve Knudsen за обнаружение того, что дочерние процессы отслеживаемого приложения могут продолжать работу при остановке службы, а также за обнаружение отсутствующего значения реестра для AppDirectory, которое путает NSSM.
Спасибо Peter Wagemans и Laszlo Keresztfalvi за предложение ограничить перезапуски.
Спасибо Eugene Lifshitz за обнаружение краевого случая в CreateProcess() и за совет по правильному построению messages.mc в путях, содержащих пробелы.
Спасибо Rob Sharp за указание на то, что NSSM не уважает значение реестра AppEnvironment, используемое srvany.
Спасибо Szymon Nowak за помощь в обеспечении совместимости с Windows 2000.
Спасибо François-Régis Tardy и Gildas le Nadan за французский перевод.
Спасибо Emilio Frini за обнаружение того, что французский язык был непреднамеренно установлен как основной язык, когда язык отображения пользователя не был переведен.
Спасибо Riccardo Gusmeroli и Marco Certelli за итальянский перевод.Спасибо Eric Cheldelin за вдохновение для генерации события Control-C при остановке.
Спасибо Brian Baxter за предложение по экранированию кавычек из командной строки.
Спасибо Russ Holmann за предложение сделать таймаут остановки настраиваемым.
Спасибо Paul Spause за обнаружение ошибки с умолчательными значениями реестра.
Спасибо BUGHUNTER за обнаружение дополнительных ошибок в графическом интерфейсе.
Спасибо Doug Watson за предложение вращения файлов.
Спасибо Арслан Сайдуганов за предложение установки приоритета процесса.
Спасибо Robert Middleton за предложение и черновую реализацию поддержки аффинности процесса.
Спасибо Andrew RedzMax за предложение безусловного задержки перезапуска.
Спасибо Bryan Senseman за обнаружение ошибки с приложениями, которые перенаправляют stdout и/или stderr и пытаются читать из stdin.
Спасибо Czenda Czendov за помощь с Visual Studio 2013 и Server 2012R2.
Спасибо Alessandro Gherardi за отчет и черновую фиксацию ошибки, при которой второе перезапускание приложения приводило к повреждению окружения.
Спасибо Hadrien Kohl за предложение отключения меню окна консоли.
Спасибо Allen Vailliencourt за обнаружение ошибок при настройке службы для выполнения под локальным пользовательским аккаунтом.
Спасибо Sam Townsend за обнаружение регрессии с TerminateProcess(). Лицензия
---------
NSSM находится в общественном достоянии. Вы можете безусловно использовать его и/или исходный код для любой цели, которую пожелаете.