Как исправить ошибку «Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService»?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В процессе администрирования клиент-серверных баз 1С:Предприятие мы можем столкнуться с критической ошибкой, блокирующей работу пользователей. Сообщение выглядит так: «Не найдено ни одного сервера с размещенным сервисом serviceName=SessionDataService». Иногда вместо SessionDataService может фигурировать NumerationService или другие сервисы кластера.

Эта ошибка означает, что менеджер кластера (rmngr) не может выделить или обнаружить рабочий процесс (rphost), который должен отвечать за конкретную функциональность (хранение сеансовых данных, нумерацию и т.д.). Давайте разберем детально, почему это происходит и как мы можем исправить ситуацию, опираясь на опыт сообщества и технические особенности платформы.

1. Проверка дискового пространства и логов

Самая банальная, но частая причина — физическая нехватка места на сервере. Сервисы кластера активно пишут временные файлы и логи.

Давайте проверим следующие локации:

  1. Папка srvinfo: Проверьте диск, на котором установлена папка srvinfo (обычно в Program Files или ProgramData). Если места нет (0 байт или критически мало), сервис не сможет инициализироваться. Это может произойти из-за разрастания логов полнотекстового поиска или журнала регистрации.
  2. Журналы транзакций SQL: Если используется MS SQL, проверьте размер файлов .ldf. Если модель восстановления (Recovery Model) стоит "Full" и бэкапы журнала не делаются, файл может занять всё место.

    Решение: Переключить модель восстановления в "Simple" (Простая) и выполнить операцию "Shrink" (Сжать) для файлов базы данных.

  3. Домашние директории на Linux: Если сервер на Linux, проверьте папку /home/usr1cv8/. Она может быть забита логами или дампами (core dumps).

2. Настройка требований назначения функциональности

Если с ресурсами все в порядке, часто помогает явная настройка правил работы кластера. Механизм автоматического распределения сервисов иногда дает сбой, особенно после изменения конфигурации серверов.

Выполним следующие действия в консоли администрирования серверов 1С:

  1. Откройте ветку вашего кластера.
  2. Перейдите в раздел «Требования назначения функциональности».
  3. Создайте новое требование.
  4. В поле «Для» (Тип требования) выберите: Назначить.
  5. В поле «Имя сервиса» оставьте пустым (для всех) или выберите конкретный проблемный сервис (например, SessionDataService).
  6. Примените изменения («Применить»).

Это принудительно заставляет кластер назначить функциональность на доступные рабочие серверы.

3. "Зависшие" процессы и кэш сервера

Бывает ситуация, когда служба перезапущена, но файлы данных остаются заблокированы зависшими процессами или поврежденным кэшем.

Попробуем выполнить "глубокую" очистку:

  1. Остановите службу «Агент сервера 1С:Предприятия».
  2. Откройте «Диспетчер задач» (Windows) или используйте top/ps (Linux). Убедитесь, что процессы rphost, rmngr, ragent полностью исчезли. Если они висят — завершите их принудительно (kill).
  3. Зайдите в папку srvinfo (где хранятся настройки кластера).
  4. Найдите подпапку reg_1541 (или другой порт). В ней хранятся папки с GUID баз данных.
  5. Если ошибка возникла после неудачного создания/развертывания базы, найдите папку-сироту (GUID которой не соответствует ни одной рабочей базе в списке 1CV8Clst.lst, но дата изменения свежая) и удалите её. Иногда помогает полная очистка папки snccntx (сеансовые данные), но будьте осторожны — это сбросит текущие сеансы.
  6. Запустите службу обратно.

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


C:\Users\<ИмяПользователя>\AppData\Local\1C\1cv8
C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8

4. Ошибка serviceName=NumerationService и метаданные

Если ошибка касается сервиса нумерации (NumerationService), причина часто кроется не в сервере, а в данных самой конфигурации. Это происходит, когда платформа не может присвоить новый номер объекту.

Проанализируем частые причины:

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

5. Сетевые настройки и порты

Сервисы кластера общаются между собой по динамическим портам. Если сетевая конфигурация нарушена, rmngr не "видит" rphost.

Рассмотрим, что нужно проверить:

  1. Файл hosts: Убедитесь, что имя сервера в файле hosts (на самом сервере) разрешается в реальный IP-адрес сети, а не только в 127.0.0.1. Это критично для корректной работы сервиса сеансовых данных.
  2. Диапазон портов: По умолчанию диапазон портов 1560-1591. Убедитесь, что брандмауэр Windows или внешний фаервол не блокирует трафик между процессами 1С внутри этого диапазона, даже если все процессы запущены на одной машине.
  3. Порты агента: Проверьте, на каких портах запущен агент. Если вы меняли стандартный порт 1541 на другой (например, 1641), убедитесь, что клиентское приложение стучится в правильный порт.

6. Пересоздание регистрации базы

Иногда файл описания кластера рассинхронизируется с реальным положением дел в СУБД. Попробуем простой метод перерегистрации:

  1. В консоли кластера удалите проблемную информационную базу. Внимание: выберите пункт «Оставить без изменений» (НЕ удалять из СУБД).
  2. Создайте новую информационную базу в консоли, указав параметры подключения к той же самой базе SQL, которая уже существует.

Это действие обновляет запись в реестре кластера и часто устраняет фантомные ошибки сервисов.

7. Ограничение памяти (Memory Limit)

Ошибка может возникать из-за агрессивного потребления памяти SQL сервером, из-за чего процессам 1С (rphost) не хватает ресурсов для старта сервиса.

Рекомендуем настроить ограничения:

Резюме

Ошибка serviceName=SessionDataService чаще всего решается административными мерами. Начните с проверки свободного места и простой перезагрузки службы с убийством зависших процессов. Если не помогло — используйте настройку «Требования назначения функциональности» и проверьте сетевое разрешение имен. В крайних случаях помогает переустановка платформы на более свежий релиз, так как в некоторых версиях (например, 8.3.10-11) были зарегистрированы официальные ошибки с подобным поведением.

← На главную