В процессе администрирования клиент-серверных баз 1С:Предприятие мы можем столкнуться с критической ошибкой, блокирующей работу пользователей. Сообщение выглядит так: «Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService». Иногда вместо SessionDataService может фигурировать NumerationService или другие сервисы кластера.
Эта ошибка означает, что менеджер кластера (rmngr) не может выделить или обнаружить рабочий процесс (rphost), который должен отвечать за конкретную функциональность (хранение сеансовых данных, нумерацию и т.д.). Давайте разберем детально, почему это происходит и как мы можем исправить ситуацию, опираясь на опыт сообщества и технические особенности платформы.
Самая банальная, но частая причина — физическая нехватка места на сервере. Сервисы кластера активно пишут временные файлы и логи.
Давайте проверим следующие локации:
srvinfo (обычно в Program Files или ProgramData). Если места нет (0 байт или критически мало), сервис не сможет инициализироваться. Это может произойти из-за разрастания логов полнотекстового поиска или журнала регистрации..ldf. Если модель восстановления (Recovery Model) стоит "Full" и бэкапы журнала не делаются, файл может занять всё место.
Решение: Переключить модель восстановления в "Simple" (Простая) и выполнить операцию "Shrink" (Сжать) для файлов базы данных.
/home/usr1cv8/. Она может быть забита логами или дампами (core dumps).Если с ресурсами все в порядке, часто помогает явная настройка правил работы кластера. Механизм автоматического распределения сервисов иногда дает сбой, особенно после изменения конфигурации серверов.
Выполним следующие действия в консоли администрирования серверов 1С:
SessionDataService).Это принудительно заставляет кластер назначить функциональность на доступные рабочие серверы.
Бывает ситуация, когда служба перезапущена, но файлы данных остаются заблокированы зависшими процессами или поврежденным кэшем.
Попробуем выполнить "глубокую" очистку:
top/ps (Linux). Убедитесь, что процессы rphost, rmngr, ragent полностью исчезли. Если они висят — завершите их принудительно (kill).srvinfo (где хранятся настройки кластера).reg_1541 (или другой порт). В ней хранятся папки с GUID баз данных.1CV8Clst.lst, но дата изменения свежая) и удалите её. Иногда помогает полная очистка папки snccntx (сеансовые данные), но будьте осторожны — это сбросит текущие сеансы.Также не забываем про локальный кэш клиента, если ошибка возникает только на конкретном рабочем месте. Удалите папки с кэшем 1С по путям:
C:\Users\<ИмяПользователя>\AppData\Local\1C\1cv8
C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8
Если ошибка касается сервиса нумерации (NumerationService), причина часто кроется не в сервере, а в данных самой конфигурации. Это происходит, когда платформа не может присвоить новый номер объекту.
Проанализируем частые причины:
Решение: Вернуть прежнюю длину кода или исправить вручную коды последних элементов, чтобы автонумерация могла продолжить работу.
Сервисы кластера общаются между собой по динамическим портам. Если сетевая конфигурация нарушена, rmngr не "видит" rphost.
Рассмотрим, что нужно проверить:
hosts (на самом сервере) разрешается в реальный IP-адрес сети, а не только в 127.0.0.1. Это критично для корректной работы сервиса сеансовых данных.Иногда файл описания кластера рассинхронизируется с реальным положением дел в СУБД. Попробуем простой метод перерегистрации:
Это действие обновляет запись в реестре кластера и часто устраняет фантомные ошибки сервисов.
Ошибка может возникать из-за агрессивного потребления памяти SQL сервером, из-за чего процессам 1С (rphost) не хватает ресурсов для старта сервиса.
Рекомендуем настроить ограничения:
Ошибка serviceName=SessionDataService чаще всего решается административными мерами. Начните с проверки свободного места и простой перезагрузки службы с убийством зависших процессов. Если не помогло — используйте настройку «Требования назначения функциональности» и проверьте сетевое разрешение имен. В крайних случаях помогает переустановка платформы на более свежий релиз, так как в некоторых версиях (например, 8.3.10-11) были зарегистрированы официальные ошибки с подобным поведением.