Агент сервера 1С запускается и останавливается: причины и решение

Служба «Агент сервера 1С:Предприятие» (ragent) запускается и через 2-5 секунд останавливается. В журнале событий Windows — ошибка с источником «1CV8» или «Service Control Manager». Пользователи не могут подключиться к базам, работа парализована.

Проблема в том, что ragent — корневой процесс кластера. Без него не запустятся ни менеджер кластера (rmngr), ни рабочие процессы (rphost). Если ragent падает при старте — весь кластер мёртв. Разберём пять типичных причин с диагностикой и конкретными командами для исправления.

Причина 1 — повреждён кеш кластера

Самая частая причина. ragent при запуске читает файлы реестра кластера из папки srvinfo\reg_1541\. Если файлы повреждены после аварийного завершения — отключения питания, BSOD, принудительного kill — ragent не может разобрать структуру. Служба завершается с ошибкой.

Характерный признак: служба работала нормально, произошёл сбой (перезагрузка, зависание), после этого ragent перестал запускаться. В журнале событий — ошибка при инициализации кластера.

Диагностика

Проверьте файлы реестра кластера:

• Windows: C:\Program Files\1cv8\srvinfo\reg_1541\
• Linux: /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/

Откройте srvribrg.lst и 1CV8Reg.lst текстовым редактором. Файлы должны содержать читаемую структуру с UUID кластера и списком баз. Если файл пуст, содержит нулевые байты или обрывается на середине строки — кеш повреждён.

Дополнительно проверьте журнал событий Windows:

Get-EventLog -LogName Application -Source "1CV8*" -Newest 20 | Format-List

Решение

1. Остановите службу: net stop "1C:Enterprise 8.3 Server Agent"
2. Сделайте резервную копию папки reg_1541 целиком.
3. Переименуйте папку: ren reg_1541 reg_1541_backup. Или удалите конкретные повреждённые файлы — srvribrg.lst, 1CV8Reg.lst.
4. Запустите службу: net start "1C:Enterprise 8.3 Server Agent"
5. ragent создаст чистый реестр автоматически. Откройте консоль администрирования серверов 1С и заново зарегистрируйте информационные базы.

Регистрация через утилиту rac:

rac infobase --cluster=<cluster-uuid> create --name="MyBase" --dbms=MSSQLServer --db-server=localhost --db-name=mybase --db-user=sa --db-pwd=***

Подробнее о настройке кластера после пересоздания реестра — в руководстве по настройке кластера 1С.

Причина 2 — конфликт портов

ragent по умолчанию слушает порт 1540, rmngr — 1541, rphost — 1560 и далее. Если порт 1540 занят другим процессом, ragent не может привязаться и завершается. Порт могут занять второй экземпляр ragent, Sentinel HASP или остаток от предыдущей версии платформы.

Диагностика

Проверьте, кто занимает порт 1540. На Windows:

netstat -ano | findstr ":1540"

На Linux:

ss -tlnp | grep ":1540"

Если в выводе есть строка с LISTENING и PID, отличным от вашего ragent — порт занят. Узнайте имя процесса по PID:

tasklist /FI "PID eq <PID>"

Частая ситуация: на сервере установлены две версии платформы 1С (например, 8.3.20 и 8.3.25). ragent от старой версии запустился первым и занял порт.

Решение

Два варианта:

1. Освободить порт. Остановите процесс, занимающий порт. Если это ragent от старой версии — отключите его службу: sc config "1C:Enterprise 8.3 Server Agent (x86-64) (8.3.20.XXXX)" start= disabled. Затем перезапустите нужную версию.
2. Указать другой порт. В свойствах службы добавьте параметр -port 1640 в строку запуска. Не забудьте обновить адрес в настройках тонких клиентов и консоли администрирования.

Проблемы с портами кластера часто связаны с ошибкой «Local Cluster Unavailable» — если ragent запустился, но rmngr не может занять порт 1541.

Причина 3 — недостаточно прав учётной записи службы

Служба ragent работает от имени учётной записи — обычно USR1CV8 (создаётся при установке) или указанной вручную. Если у учётной записи нет доступа к каталогу srvinfo, временным файлам или сетевым ресурсам — ragent не может инициализироваться и останавливается.

Типичные сценарии: администратор сменил учётную запись службы, сбросились NTFS-права после обновления Windows, домен заблокировал учётную запись из-за просроченного пароля.

Диагностика

Проверьте, от какой учётной записи запущена служба:

sc qc "1C:Enterprise 8.3 Server Agent"

В строке SERVICE_START_NAME указана учётная запись. Проверьте NTFS-права этой учётной записи на папку srvinfo:

icacls "C:\Program Files\1cv8\srvinfo"

Учётная запись должна иметь полный доступ (Full Control) на srvinfo и все вложенные папки. Также проверьте доступ к временной папке пользователя и каталогу bin текущей версии платформы.

Решение

Назначьте полный доступ через PowerShell:

$acl = Get-Acl "C:\Program Files\1cv8\srvinfo"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule("USR1CV8","FullControl","ContainerInherit,ObjectInherit","None","Allow")
$acl.SetAccessRule($rule)
Set-Acl "C:\Program Files\1cv8\srvinfo" $acl

На Linux:

chown -R usr1cv8:grp1cv8 /home/usr1cv8/.1cv8/
chmod -R 755 /home/usr1cv8/.1cv8/

Альтернатива: переключите службу на Local System (в services.msc → вкладка «Вход в систему» → «С системной учётной записью»). Это решает проблему прав, но ограничивает доступ к сетевым ресурсам. Если базы на сетевом SQL Server — лучше использовать доменную учётную запись с правильными правами.

Убедитесь, что учётная запись имеет право «Вход в качестве службы»: secpol.msc → Локальные политики → Назначение прав пользователя → Вход в качестве службы.

Причина 4 — несовместимость версий после обновления

После обновления платформы 1С (например, с 8.3.20 на 8.3.25) формат файлов кеша кластера может измениться. Новый ragent пытается прочитать старые файлы из reg_1541, не понимает формат и падает. Служба запускается, читает несовместимый кеш — и сразу останавливается.

Вторая разновидность: на сервере остались запущенные процессы от старой версии (rmngr, rphost), а новый ragent пытается взаимодействовать с ними. Версии протоколов не совпадают — результат тот же.

Диагностика

Проверьте, какие версии процессов 1С запущены:

tasklist /FI "IMAGENAME eq ragent.exe" /V
tasklist /FI "IMAGENAME eq rmngr.exe" /V
tasklist /FI "IMAGENAME eq rphost.exe" /V

Если в списке есть процессы от разных версий (пути к исполняемым файлам содержат разные номера версий) — это конфликт. Также проверьте, какая версия прописана в службе:

sc qc "1C:Enterprise 8.3 Server Agent" | findstr "BINARY_PATH_NAME"

Решение

1. Остановите все службы 1С (всех версий).
2. Принудительно завершите оставшиеся процессы: taskkill /F /IM ragent.exe, taskkill /F /IM rmngr.exe, taskkill /F /IM rphost.exe.
3. Очистите кеш кластера — переименуйте папку reg_1541 (аналогично причине 1).
4. Запустите службу нужной версии.
5. Зарегистрируйте информационные базы заново.

Старые версии служб лучше отключить: sc config "1C:Enterprise 8.3 Server Agent (x86-64) (8.3.20.XXXX)" start= disabled. Оставьте только актуальную версию.

Причина 5 — нехватка оперативной памяти

ragent при запуске инициализирует структуры данных кластера и запускает дочерние процессы — rmngr, затем rphost. Если на сервере свободно менее 500 МБ RAM, операционная система может завершить ragent при попытке выделить память. Особенно критично, если на сервере одновременно работают SQL Server, антивирус, RDP-сессии и другие службы.

Диагностика

Проверьте текущее потребление памяти. На Windows:

systeminfo | findstr "Физическая память"

Или через PowerShell — точнее:

Get-Process | Sort-Object WorkingSet64 -Descending | Select-Object -First 10 Name, @{N='RAM_MB';E={[math]::Round($_.WorkingSet64/1MB)}}

Если свободной памяти менее 1 ГБ, а в топе — sqlservr.exe с десятками гигабайт — SQL Server занял всю доступную RAM. Это штатное поведение SQL Server: он забирает память и не отдаёт, пока не попросят.

Решение

Три направления:

1. Ограничьте SQL Server. В SQL Server Management Studio: правый клик по серверу → Свойства → Память → установите «Максимальный объём серверной памяти». Формула: общая RAM минус 4 ГБ (для ОС) минус 2 ГБ на каждый rphost. Для сервера с 32 ГБ и 2 rphost: 32 — 4 — 4 = 24 ГБ максимум для SQL.
2. Увеличьте RAM. Для серверов 1С с 30+ пользователями 128 ГБ ECC — проверенный стандарт. Подробнее — в требованиях к серверу для 1С.
3. Ограничьте число rphost. Каждый рабочий процесс потребляет 500 МБ — 4 ГБ. Если rphost слишком много для имеющейся памяти — уменьшите количество в свойствах рабочего сервера кластера. Подробнее о настройке рабочих процессов — в статье про ошибку «Свободный рабочий процесс не найден».

Если ничего не помогло

Вы проверили все пять причин, а ragent по-прежнему падает при запуске? Включите технологический журнал 1С — он покажет, на каком этапе инициализации происходит сбой. Создайте файл logcfg.xml в каталоге conf платформы с записью событий EXCP и PROC.

Также попробуйте запустить ragent вручную из командной строки (не как службу) — ошибки выведутся прямо в консоль:

"C:\Program Files\1cv8\8.3.25.XXXX\bin\ragent.exe" -debug -port 1540 -regport 1541 -range 1560:1591

Если разобраться самостоятельно не удаётся — оставьте заявку. Проведём удалённую диагностику вашего сервера.

Как предотвратить проблему

ragent падает не случайно — всегда есть предпосылки. Три направления профилактики: мониторинг, резервное копирование, правильная инфраструктура.

Мониторинг

• Статус службы: настройте проверку каждые 5 минут через Task Scheduler или Zabbix. При остановке — автоматический перезапуск и уведомление администратору. В свойствах службы (services.msc) на вкладке «Восстановление» задайте «Перезапуск службы» для первого и второго сбоя
• Порт 1540: TCP-check порта ragent покажет, жив ли кластер, раньше, чем позвонит пользователь
• RAM: отслеживайте свободную память. Порог оповещения — менее 2 ГБ свободных. Проблемы с памятью решаются проще, пока сервер ещё работает

Резервное копирование кеша кластера

Папка reg_1541 занимает килобайты, но её потеря стоит часов простоя — заново регистрировать все базы. Копируйте ежедневно. Подробнее о стратегии резервного копирования — в руководстве по бэкапу 1С.

Инфраструктура

Надёжный сервер снижает вероятность аварий. ECC-память защищает от битовых ошибок, RAID — от потери данных при сбое диска, UPS — от некорректного завершения при отключении питания. Именно некорректное завершение — главная причина повреждения кеша кластера.

Как мы тестируем серверное оборудование на реальных нагрузках 1С — в описании нашей методологии.

Вопросы и ответы