Не запускается сервер 1С: почему агент сервера 1С:Предприятия 8.3 не стартует и как его поднять

Если не запускается сервер 1С — служба «Агент сервера 1С:Предприятия 8.3» не стартует или запускается и сразу останавливается, — причина почти всегда одна из пяти: проблема с учётной записью службы (ошибка 1069, сменился пароль USR1CV8), занят порт 1540 или 1541, у службы нет прав на каталог srvinfo, повреждены файлы кластера после аварийного выключения или служба после обновления платформы указывает не на ту версию. Начинайте с журнала событий Windows: в нём почти всегда написано, что именно не понравилось службе.

Ниже порядок проверки на сервере Windows. Он рассчитан на администратора или опытного пользователя; где действие опасно для боевого сервера, я отдельно предупреждаю.

Шаг 1. Посмотрите, что пишет Windows

1. Откройте services.msc и найдите службу агента сервера. В русской Windows она обычно называется «Агент сервера 1С:Предприятия 8.3» (с указанием разрядности), в английской — «1C:Enterprise 8.3 Server Agent».
2. Попробуйте запустить её вручную и запомните текст ошибки, если он появится.
3. Откройте «Просмотр событий» → «Журналы Windows» → «Система» и «Приложение». Найдите события в момент запуска службы.

Типичные варианты:

• Ошибка 1069 «Служба не запущена из-за ошибки входа в систему» — проблема с учётной записью службы, шаг 2.
• Служба запускается и сразу останавливается без внятной ошибки — порт, права, файлы кластера, шаги 3–5.
• Ошибка загрузки библиотек — повреждена установка платформы, шаг 6.

Шаг 2. Учётная запись службы и ошибка 1069

По умолчанию служба сервера 1С работает от локального пользователя USR1CV8. Ошибку 1069 Windows выдаёт, когда служба не может войти под этой учётной записью.

Причины:

• пароль пользователя сменили, а в свойствах службы остался старый;
• истёк срок действия пароля;
• учётная запись заблокирована политикой безопасности;
• у пользователя нет права «Вход в качестве службы».

Что делать:

1. В services.msc откройте свойства службы, вкладка «Вход в систему». Укажите учётную запись .\USR1CV8 и актуальный пароль в оба поля.
2. В lusrmgr.msc проверьте, не заблокирован ли пользователь, и включите «Срок действия пароля не ограничен», чтобы история не повторилась.
3. В secpol.msc → «Локальные политики» → «Назначение прав пользователя» найдите «Вход в качестве службы» и убедитесь, что USR1CV8 там есть.
4. Если служба работает от другой учётной записи, у неё должны быть полные права на каталог srvinfo, а в клиент-серверной базе — доступ к базам в СУБД.

Шаг 3. Не занят ли порт

Агент сервера по умолчанию слушает порт 1540, менеджер кластера — 1541, рабочие процессы — диапазон 1560–1591. Если порт держит другой процесс, служба не поднимется.

1. Выполните в командной строке:

netstat -ano | findstr :1540

1. Если порт занят, запомните PID в последнем столбце и найдите процесс в диспетчере задач. Это может быть зависший ragent после неудачной остановки, вторая служба 1С другой версии или посторонняя программа.
2. Повторите для 1541.
3. Освободите порт и запустите службу.

Если порт оказывается занят после каждой перезагрузки, частая причина — Windows выдала его другому процессу из своего динамического диапазона портов. Текущий диапазон показывает команда netsh int ipv4 show dynamicport tcp. Решение — сдвинуть динамический диапазон так, чтобы он не пересекался с портами 1С, или перенести порты 1С. Это изменение сетевых настроек сервера, делайте его осознанно и вне рабочего времени.

Шаг 4. Права на каталог srvinfo

Каталог srvinfo — рабочая папка сервера: в ней лежат настройки кластера, список зарегистрированных баз, журналы регистрации и сеансовые данные. По умолчанию это C:\Program Files\1cv8\srvinfo, но точный путь задаётся параметром -d в строке запуска службы — его видно в свойствах службы, в поле с путём к исполняемому файлу.

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

Шаг 5. Повреждённые файлы кластера

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

Порядок, от безопасного к радикальному:

1. Сделайте копию всего каталога srvinfo. Без неё дальше не идите.
2. Очистите сеансовые данные. Остановите службу и удалите в каталоге кластера (подкаталог вида reg_1541) папку или файлы snccntx. Это кэш сеансов, после удаления он создаётся заново.
3. Попробуйте запустить службу. Часто этого достаточно.
4. Крайняя мера: остановите службу, переименуйте srvinfo в srvinfo.old и запустите службу. Сервер создаст пустой каталог и поднимется, но все настройки кластера и список баз пропадут: базы придётся регистрировать заново. Данные самих баз в СУБД при этом не затрагиваются.

Шаг 6. Версия платформы и установка

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

Таблица: симптом, причина, что делать

Как убедиться, что сервер действительно поднялся

Статус «Выполняется» в списке служб ещё не значит, что всё в порядке. После запуска проверьте:

1. В диспетчере задач есть процессы ragent, rmngr и хотя бы один rphost. Если ragent есть, а rmngr и rphost не появляются, проблема в настройках кластера, портах рабочих процессов или правах.
2. Команда netstat -ano | findstr :1540 показывает, что порт слушает именно процесс ragent.
3. Консоль администрирования серверов 1С подключается к кластеру, в нём видны рабочие серверы и зарегистрированные базы.
4. Пользователь с другого компьютера заходит в базу. Если не заходит, проверяйте брандмауэр, имя сервера и лицензии — это уже вопрос соединения, а не запуска службы.

Как не попадать в это снова

• Сохраняйте копию каталога srvinfo перед каждым обновлением платформы и периодически по расписанию: восстановить список баз и настройки кластера из копии — минуты, а не часы.
• Поставьте серверу бесперебойник: большая часть повреждений srvinfo случается после аварийного выключения.
• Задайте учётной записи службы бессрочный пароль и не меняйте его без обновления в свойствах службы.
• Записывайте нестандартные порты и пути, если их меняли, — следующий администратор скажет спасибо.

Если сервер на Linux

Логика та же: учётная запись службы, порты, права на каталог данных кластера, версия платформы. Отличаются инструменты — статус и ошибки службы смотрят через systemctl status и journalctl, занятые порты — через ss -ltnp. Имена юнитов и пути зависят от версии платформы и способа установки, поэтому сверяйтесь с тем, как сервер был установлен у вас.

Короткий чек-лист

1. Журнал событий Windows: текст ошибки при запуске службы.
2. Учётная запись службы: пароль, блокировка, право «Вход в качестве службы».
3. Порты 1540, 1541 и диапазон рабочих процессов свободны.
4. Полные права службы на srvinfo, исключения в антивирусе.
5. Копия srvinfo, затем очистка snccntx.
6. Путь к ragent.exe в службе соответствует установленной версии.
7. Крайняя мера — пересоздание srvinfo с последующей регистрацией баз.

Если сервер 1С не поднимается, а работа стоит, помогу удалённо: разберу причину и настрою сервер 1С, восстановлю конфигурацию кластера 1С и зарегистрированные базы или настрою терминальный сервер, чтобы сотрудники работали стабильно и из офиса, и удалённо.