Запуск nginx службой в Windows

Запуск nginx службой в Windows будет осуществляться с помощью программы Windows Service Wrapper.
Скачать её можно тут: http://download.java.net/maven/2/com/sun/winsw/winsw/.
Необходимо скачать .exe файл нужной версии (отлично подошла версия 1.7) и переместить в корень директории, где расположен nginx (например D:\Programs\nginx-1.7.2\), переименовав данный файл в ngsrvc.exe. В той же директории необходимо создать xml файл с именем ngsrvc.xml.

Содержимое файла ngsrvc.xml

• D:\Programs\nginx-1.7.2\nginx.exe путь до исполняемого файла nginx
• D:\Programs\nginx-1.7.2\service_logs\ путь, по которому Windows Service Wrapper будет хранить свои лог файлы (если директории нет, нужно её создать).
• В передаются параметры обязательно необходимые для корректного запуска nginx как сервис, дело в том что nginx при формировании путей использует косую черту (как в Linux — /), соответственно при использовании nginx в Windows необходимо использовать обратную косую черту (обратный слеш — \). Именно по-этому при запуске и остановке сервиса указывается рабочая директория параметром -p и относительный путь к конфигурационному файлу -c.

Без корректного указания параметров -c и -p появлялась ошибка в логах Windows Service Wrapper примерного содержания:

Для того, чтобы зарегистрировать сервис, необходимо запустить: ngsrvc.exe install , после чего указанный сервис появится в оснастке Администрирование -> Службы , откуда станет возможно ей управлять.
Не забудте создать папку service_logs, как указано в xml файле.
Дополнительные команды:

• Запустить — ngsrvc.exe start
• Остановить — ngsrvc.exe stop
• Рестартовать — ngsrvc.exe restart
• Деинсталляция службы — ngsrvc.exe uninstall

Архив с программой и конфигурационным файлом: ngsrvc

Пилим свою службу Windows – руководство для «не настоящих программистов»

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

Статья будет полезна тем, кто, как и я — «программист не настоящий».

Зачем нужна служба, если есть назначенные задания

В отличие от назначенных заданий служба работает постоянно, запускается при старте ПК и может управляться средствами Windows. А еще регулярно запускаемому скрипту могут понадобиться данные с предыдущего запуска, и может быть полезно получение данных из внешних источников — например, в случае TCP или Web сервера.

Лично мне за последние пять лет приходилось создавать службу три с половиной раза:

• Потребовалось создать сервис на fail2ban для Windows 2003., который работал с логами FileZilla и Apache, а при подозрении на брутфорс блокировал IP штатными средствами Windows — ipsec.
• Аналог телнет-сервера для домашних версий Windows. Понадобилось выполнять команды на удаленных рабочих станциях, которые были под управлением Windows 7 Home. По сути, вторая попытка поиграть в службы.
• Музыкальный проигрыватель для торгового зала под Windows. Задачу по ТЗ можно было решить при помощи mpd и пачки скриптов, но я решил — если уж делать скрипты, то почему бы и не «сваять» проигрыватель самому. За основу взял библиотеку BASS.dll.
• Когда выбирали веб-сервер с поддержкой загрузки файлов под Windows, одним из вариантов был HFS. Сам по себе работать он не может, поэтому пришлось «запихивать» его в службу. В результате решение не понравилось, и просто установили «тему» Apaxy на web-сервере Apache.

Для создания службы можно использовать взрослые языки программирования вроде C. Но если вы не хотите связываться с Visual Studio, то возьмите готовые утилиты. Существуют платные решения вроде FireDaemon Pro или AlwaysUp, но мы традиционно сосредоточимся на бесплатных.

Способ первый. От Microsoft

Этот уже немолодой механизм состоит из двух компонентов: утилиты instsrv.exe для установки сервиса и srvany.exe — процесса для запуска любых исполняемых файлов. Предположим, что мы создали веб-сервер на PowerShell при помощи модуля Polaris. Скрипт будет предельно прост:

Работа так называемого «сервера».

Теперь попробуем превратить скрипт в службу. Для этого скачаем Windows Resource Kit Tools, где будут наши утилиты. Начнем с того, что установим пустой сервис командой:

Где WebServ — имя нашего нового сервиса. При необходимости через оснастку services.msc можно задать пользователя, под которым будет запускаться служба, и разрешить взаимодействие с рабочим столом.

Теперь пропишем путь к нашему скрипту при помощи магии реестра. Параметры службы есть в разделе реестра HKLM\SYSTEM\CurrentControlSet\Services\WebServ. В нем нам нужно добавить новый раздел Parameters и создать там строковый параметр Application, указав в нем путь к исполняемому файлу. В случае скрипта PowerShell он будет выглядеть так:

Настроенная служба.

Можно запустить и радоваться.

Работающая служба.

Однако у этого способа есть недостатки:

• Утилиты старые, разработаны до изобретения PowerShell, UAC и прочих вещей.
• Srvany не контролирует работу приложения. Даже если оно выпадет в ошибку, служба продолжит свое дело как ни в чем не бывало.
• Придется донастраивать и копаться в реестре. Вы же помните, что копаться в реестре небезопасно?

Поэтому перейдем к методу, частично лишенному этих проблем.

Способ второй, почти взрослый

Существует утилита под названием NSSM — Non-Sucking Service Manager, что можно перевести как не-плохой менеджер служб. В отличие от предыдущей, она поддерживается разработчиком, и исходный код опубликован на сайте. Помимо обычного способа, доступна и установка через пакетный менеджер Chocolately.

Создать сервис можно из обычной командной строки, вооружившись документацией на сайте разработчика. Но мы воспользуемся PowerShell. Потому что можем, разумеется.

Установка через PowerShell.

Для разнообразия проверим работу службы не браузером, а тоже через PowerShell командой Invoke-RestMethod.

И вправду работает.

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

GUI запускается командой:

Настроить можно даже приоритет и использование ядер процессора.

Действительно, возможностей куда больше, чем у srvany и ряда других аналогов. Из минусов бросается в глаза недостаточный контроль над всем процессом.

Налицо нехватка «жести». Поэтому я перейду к самому хардкорному методу из всех опробованных.

Способ третий. AutoIT

Поскольку я давний любитель этого скриптового языка, то не смог пройти мимо библиотеки под названием _Services_UDF v4. Она снабжена богатой документацией и примерами, поэтому под спойлером сразу приведу полный текст получившегося скрипта.

Итак, попробуем «завернуть» в нее наш веб-сервис:

Разберу подробнее момент запуска приложения. Он начинается после операции $bServiceRunning = True и превращается в, казалось бы, бесконечный цикл. На самом деле этот процесс прервется, как только служба получит сигнал о завершении — будь то выход из системы или остановка вручную.

Поскольку программа для скрипта является внешней (powershell.exe), то после выхода из цикла нам нужно закончить ее работу с помощью ProcessClose.

Для этого скрипт необходимо скомпилировать в .exe, а затем установить службу, запустив exe с ключом -i.

Оно работает!

Разумеется, этот способ не самый удобный, и все дополнительные возможности придется реализовывать самостоятельно, будь то повторный запуск приложения при сбое или ротация логов. Но зато он дает полный контроль над происходящим. Да и сделать в итоге можно куда больше — от уведомления в Telegram о сбое службы до IPC-взаимодействия с другими программами. И вдобавок — на скриптовом языке, без установки и изучения Visual Studio.

Расскажите, а вам приходилось превращать скрипты и приложения в службы?

Windows service wrapper что это

Windows Service Wrapper in a permissive license

WinSW wraps and manages any application as a Windows service.

We are actively developing WinSW 3. Please refer to the v2 branch for previous version documentation.

WinSW 3 can run on Windows platforms with .NET Framework 4.6.1 or later versions installed. For systems without .NET Framework, the project provides native 64-bit and 32-bit executables based on .NET Core.

More executables can be added upon request.

.NET Framework system requirements
Preinstalled since Windows 10, version 1511 and Windows Server 2016.
Installable since Windows 7 SP1 and Windows Server 2008 R2 SP1.

.NET 5 system requirements
Supported since Windows 7 SP1, Windows Server (Core) 2012 R2 and Nano Server, version 1809.

Latest release and pre-release WinSW binaries are available on GitHub Releases.

• CI builds are available on Azure Pipelines.
• NuGet. (2.x)
• Maven packaging for executables, hosted by the Jenkins project. Binaries are available here. (2.x)

Use WinSW as a global tool

1. Take WinSW.exe or WinSW.zip from the distribution.
2. Write myapp.xml (see the XML config file specification and samples for more details).
3. Run winsw install myapp.xml [options] to install the service.
4. Run winsw start myapp.xml to start the service.
5. Run winsw status myapp.xml to see if your service is up and running.

Use WinSW as a bundled tool

1. Take WinSW.exe or WinSW.zip from the distribution, and rename the .exe to your taste (such as myapp.exe).
2. Write myapp.xml (see the XML config file specification and samples for more details).
3. Place those two files side by side, because that’s how WinSW discovers its co-related configuration.
4. Run myapp.exe install [options] to install the service.
5. Run myapp.exe start to start the service.

Sample configuration file

You write the configuration file that defines your service. The example below is a primitive example being used in the Jenkins project:

The full specification of the configuration file is available here. You can find more samples here.

WinSW is being managed by the XML configuration file.

Your renamed WinSW.exe binary also accepts the following commands:

Command	Description
install	Installs the service.
uninstall	Uninstalls the service.
start	Starts the service.
stop	Stops the service.
restart	Stops and then starts the service.
status	Checks the status of the service.
refresh	Refreshes the service properties without reinstallation.
customize	Customizes the wrapper executable.
dev	Experimental commands.

Command	Description
dev ps	Draws the process tree associated with the service.
dev kill	Terminates the service if it has stopped responding.
dev list	Lists services managed by the current executable.

Most commands require Administrator privileges to execute. WinSW will prompt for UAC in non-elevated sessions.

• Migrate to WinSW 3.x
• Configuration:
  • XML configuration file
  • Logging and error reporting
  • Extensions
• Use cases:
  • Self-restarting services
  • Deferred file operations

Contributions are welcome! See the contributing guidelines for more information.

WinSW is licensed under the MIT license.

About

A wrapper executable that can run any executable as a Windows service, in a permissive license.

Windows service wrapper что это

Nginx сам по себе не поддерживает работу как сервис. Более, того, при запуске он запускает дочерний процесс, который обслуживает соединения, а родительский процесс служит для управления. Для того, что бы остановить nginx нужно запустить его с ключем -s stop , тогда родительский процесс прибьет дочерние и корректно завершится.

Если установить nginx как сервис стандартными средствами, то при попытке остановить сервис винда тупо убивает родительский процесс, в результате дочерние процессы продолжают существовать.

Для того, что бы решить эту проблему написан wrapper, которому можно указать как корректно завершать процессы. называется сие чудо Windows Service Wrapper.

Установка Nginx как сервис

1). Скачиваем и распаковываем Nginx. Например в папку D:/nginx Скачивать тут (за одно полезно почитать эту страницу): Nginx под Windows

3). Копируем winsw в папку, куда распаковали nginx и переименовываем в D:\nginx\nginx_svc.exe

4). Создаем конфиг D:\nginx\nginx_svc.xml

Управление nginx под Linux

nginx -s stop : быстрое завершение
nginx -s quit : плавное завершение
nginx -s reload : изменение конфигурации, запуск новых рабочих процессов с новой конфигурацией, плавное завершение старых рабочих процессов
nginx -s reopen : переоткрытие лог-файлов
nginx -t : проверка конфига на ошибки

Чтобы увидеть процессы nginx, запустите утилиту командной строки tasklist:

Прочие косяки Nginx под windows

Проблема

По умолчанию длина имени виртуального хоста 32 символа. если у вас имя хоста длиньше, то получите ошибку: