Запуск 1С как сервиса: пошаговая инструкция для администратора

Работа 1С в режиме службы Windows нужна в двух типовых ситуациях: когда развёрнут сервер 1С:Предприятие и его агент должен стартовать автоматически без входа пользователя в систему, и когда файл-сервер или отдельная машина должна выполнять фоновые задачи (обмены, регламентные задания, агенты обновления) без постоянно открытой сессии. Служба стартует вместе с операционной системой, переживает перезагрузки и не зависит от того, вошёл ли кто-то в Windows.

Штатно 1С умеет регистрировать собственную службу — «Агент сервера 1С:Предприятия». Это делается либо при установке сервера (флажок «Устанавливать сервер как сервис»), либо позже командой регистрации. Все остальные сценарии — запуск толстого клиента для фоновых задач, старт сторонних обработчиков — решаются через обёртки вроде NSSM или планировщик заданий Windows.

Ниже разобраны оба подхода: штатная регистрация агента сервера и запуск произвольных процессов 1С как службы, а также проверка результата, типичные ошибки и границы, где самостоятельные эксперименты лучше прекратить.

Что именно можно запустить как службу

Под «запуском 1С как сервиса» обычно понимают три разные задачи, и их важно различать, потому что инструменты разные. Первая — агент сервера 1С:Предприятия (ragent), который обслуживает кластер и клиентские подключения. Вторая — агент сервера хранилища конфигураций (crserver). Третья — запуск исполняемого файла 1cv8.exe или 1cv8c.exe с параметрами для выполнения фоновых операций: обменов данными, выгрузок, обновления баз.

Штатной службой Windows умеет быть только серверная часть платформы. Клиентское приложение (1cv8.exe) технически можно обернуть в службу через NSSM или srvany, но это нештатный режим: приложение рассчитано на интерактивный сеанс, и в службе оно работает в изолированной сессии без рабочего стола.

Штатная регистрация агента сервера 1С

Если при установке сервера 1С флажок «Устанавливать сервер 1С:Предприятия как сервис Windows» не был отмечен, службу можно зарегистрировать позже вручную. Для этого понадобятся права локального администратора и командная строка, запущенная от имени администратора.

Команда регистрации выполняется из каталога bin соответствующей версии платформы:

"C:\Program Files\1cv8\8.3.22.1750\bin\ragent.exe" -instsrvc -usr ".\1C_Server" -pwd "ПарольУчётнойЗаписи"

Здесь -instsrvc — регистрация службы, -usr и -pwd — учётная запись, под которой будет работать агент. Если параметры учётной записи не указать, служба зарегистрируется под системной учётной записью LocalSystem, что не всегда удобно: у неё могут быть ограничения при доступе к сетевым ресурсам и СУБД.

Для удаления службы используется обратная команда ragent.exe -rmsrvc. После регистрации служба появится в консоли services.msc под именем «Агент сервера 1С:Предприятия 8.3» с типом запуска «Автоматически».

1. 1
   Создайте отдельную учётную запись для службы (например, 1C_Server) и задайте ей надёжный пароль
2. 2
   Выдайте этой учётной записи права на каталог srvinfo и доступ к серверу СУБД
3. 3
   Откройте командную строку от имени администратора
4. 4
   Выполните ragent.exe -instsrvc с параметрами -usr и -pwd
5. 5
   Откройте services.msc, найдите службу агента и запустите её
6. 6
   Проверьте, что порт 1540 прослушивается и консоль кластера подключается

Учётная запись службы и права доступа

Выбор учётной записи — самая частая причина проблем после регистрации службы. Агенту сервера нужны: полный доступ к каталогу реестра кластера (по умолчанию C:\Program Files\1cv8\srvinfo), сетевой доступ к серверу СУБД, а при использовании аутентификации Windows в базе — соответствующие права на самом SQL Server или PostgreSQL.

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

Запуск клиентских процессов 1С как службы через NSSM

Когда нужно, чтобы на сервере постоянно работал процесс 1С с фоновыми задачами (например, отдельный сеанс-обработчик обменов), штатной службы недостаточно. Распространённое решение — утилита NSSM (Non-Sucking Service Manager), которая оборачивает любой исполняемый файл в службу Windows и умеет перезапускать его при падении.

Установка выглядит так: скачанный nssm.exe запускается из командной строки с параметром install, после чего в диалоге указывается путь к 1cv8.exe и аргументы командной строки — строка подключения к базе, пользователь, пароль и параметр запуска обработки. Альтернативный вариант без сторонних утилит — планировщик заданий Windows с триггером «При запуске системы» и флажком «Выполнять вне зависимости от регистрации пользователя».

nssm install 1C_Background "C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" ENTERPRISE /S"Server\Base" /N"Robot" /P"Пароль" /DisableStartupDialogs

Важно понимать ограничение: процесс в службе работает в нулевой сессии без рабочего стола. Любое модальное окно — запрос лицензии, предупреждение безопасности, диалог обновления конфигурации — повесит процесс навсегда, потому что нажать кнопку некому. Поэтому в параметрах запуска используют /DisableStartupDialogs и /DisableStartupMessages, а код обработчика пишут без интерактивных вызовов.

Проверка результата и диагностика

После регистрации службы проверьте три вещи. Во-первых, статус службы в services.msc — она должна быть в состоянии «Выполняется» и переживать перезагрузку сервера. Во-вторых, прослушивание портов: агент сервера по умолчанию слушает порт 1540, рабочие процессы занимают диапазон 1560–1591. Проверяется командой netstat -an | find "1540". В-третьих, подключение консоли администрирования серверов 1С — если кластер виден и список баз открывается, служба работает корректно.

Если служба не стартует, первым делом смотрите журнал событий Windows (Просмотр событий → Журналы Windows → Система и Приложение). Типичные записи: ошибка входа учётной записи (неверный пароль), отказ в доступе к каталогу srvinfo, конфликт портов при наличии нескольких версий агента на одном сервере.

Типичные ошибки и ограничения

Самая частая ошибка — регистрация службы под учётной записью с истекающим паролем. Через 42 дня (стандартная политика домена) пароль меняется, служба перестаёт стартовать, и базы оказываются недоступны в самый неподходящий момент. Лечится установкой для сервисной учётной записи флажка «Срок действия пароля не ограничен» либо регулярным обновлением пароля в свойствах службы.

Вторая группа проблем — обновление платформы. После установки новой версии служба продолжает ссылаться на старый каталог bin. Если старую версию удалить, служба перестанет запускаться. Правильный порядок: остановить службу, удалить регистрацию (-rmsrvc), установить новую версию, зарегистрировать службу из нового каталога, запустить.

Третья ошибка — попытка запустить как службу конфигуратор или клиентское приложение, которое открывает диалоги. Процесс зависает в ожидании нажатия кнопки, которое никогда не произойдёт. Для фоновых сценариев код должен быть полностью неинтерактивным, а все исключения — записываться в журнал регистрации или файл лога.

Когда служба не нужна: альтернативы

Прежде чем оборачивать клиентский процесс в службу, проверьте, нельзя ли решить задачу штатно. Если база работает в клиент-серверном режиме, регламентные и фоновые задания выполняются самим кластером — отдельный процесс-робот не нужен вовсе. Для файловых баз периодические задачи надёжнее запускать через планировщик заданий по расписанию, чем держать постоянно работающий процесс.

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

Частые вопросы