Решения: rmngr блокирует rac cluster insert (ClusterConfigService, порт 1541)

Дата: 2026-01-25
Версии 1С: 8.3.27.1786 (работает), 8.3.27.1989 (проблема)
Статус: Анализ выполнен, решения предложены

Краткая формулировка проблемы

  • rac server insert требует ClusterConfigService, который размещается на рабочем сервере.
  • Первый рабочий сервер создаётся только вместе с кластером командой rac cluster insert (не через rac server insert).
  • rac cluster insert требует запущенный ragent (и доступ к RAS).
  • При запуске ragent автоматически стартует rmngr на порту 1541 (по документации 1С — «создаётся по умолчанию при первом запуске»).
  • В результате порт 1541 занят rmngr, и при выполнении rac cluster insert --port=1541 возникает ошибка вида «Запуск рабочего процесса не возможен из-за конфликта IP портов» — создание кластера через rac блокируется.

Таким образом, возникает циклическая зависимость: чтобы создать кластер, нужен свободный 1541 и работающий ragent, но ragent сразу занимает 1541 через rmngr.

Документация 1С (релевантные фрагменты)

По руководству администратора 1С:

  • /regport — порт главного менеджера кластера (rmngr), создаваемого по умолчанию при первом запуске ragent. По умолчанию: 1541.
  • /range — диапазон портов для рабочего сервера, также создаваемого по умолчанию при первом запуске ragent (например, 1560:1591).

То есть автозапуск rmngr (и по сути «дефолтного» кластера/рабочего сервера) при старте ragent — это штатное поведение платформы, а не баг. Отключить создание rmngr при старте ragent документация не позволяет.

Опыт из вашей инфраструктуры

Контейнер Версия 1С rac cluster insert Примечание
1c-server 8.3.27.1786 ✅ Успешно (port 1541) Кластер создан, worker + ClusterConfigService есть
1c-server-new 8.3.27.1989 ❌ Конфликт портов rmngr сразу на 1541, insert падает

На 1786 последовательность «запуск сервисов → rac cluster insert» сработала. На 1989 — нет. Возможные причины: иное поведение платформы 1989 (например, более ранний/агрессивный старт rmngr или рабочих процессов) или отличия в порядке запуска/очистки конфигурации.

Предлагаемые решения

Решение 1: GUI консоль администрирования 1С (рекомендуется)

Идея: Обойти блокировку со стороны rac, создав кластер через графическую консоль. GUI может по-другому взаимодействовать с уже запущенным rmngr/ragent и избежать «конфликта портов» при создании кластера.

Шаги:

  1. Установить консоль администрирования 1С на клиенте (Windows/Linux).
  2. Подключиться к RAS (например, 10.218.14.10:1545 для 1c-server-new).
  3. Создать кластер через GUI: правый клик → «Создать» → «Кластер серверов»; хост localhost, порт менеджера 1541, имя cluster1.
  4. Проверить: rac cluster list localhost:1545, затем rac server list --cluster=<UUID> localhost:1545.
  5. При необходимости зарегистрировать ИБ (prod_dev) через GUI или скрипт.

Плюсы: Не требует правок systemd/ragent, описан в ваших отчётах как рабочий обходной путь.
Минусы: Нужен доступ по GUI к серверу (проброс 1545, VPN и т.п.).

Решение 2: Сначала проверить rac cluster list (кластер уже есть)

Идея: При работающих ragent и rmngr платформа могла уже «автоматически» завести кластер. В этом случае rac cluster insert не нужен — достаточно взять UUID из rac cluster list и использовать его для rac server list, регистрации ИБ и т.д.

Шаги:

  1. Убедиться, что работают srv1cv8 и ras.
  2. Выполнить:
    bash rac cluster list localhost:1545
  3. Если вывод не пустой и есть реальный UUID (не 00000000-...):
  4. использовать этот кластер для всех дальнейших операций;
  5. проверить rac server list --cluster=<UUID> localhost:1545 (должен быть worker с ClusterConfigService).
  6. Если кластер не найден — переходить к другим решениям (GUI, другой порт, восстановление).

Плюсы: Никаких изменений конфигурации, одна команда.
Минусы: Помогает только если кластер уже зарегистрирован в RAS; на 1c-server-new при текущей конфигурации часто «кластер не создан».

Решение 3: Другой порт менеджера (regport 1542)

Идея: Заставить ragent использовать для rmngr порт 1542 вместо 1541. Тогда 1541 свободен, и теоретически rac cluster insert --port=1541 мог бы создавать кластер на 1541. Но: созданный таким образом кластер будет на 1541, а rmngr слушает 1542 — несоответствие. Поэтому логично создавать кластер на том же порту, что и rmngr — 1542. Однако тогда cluster insert будет пытаться занять 1542, который уже занят rmngr. В итоге просто смена regport на 1542 не снимает конфликт для rac cluster insert на том же хосте.

Практический смысл смены regport:

  • Развести несколько экземпляров 1С на одной машине (каждый со своим regport/range).
  • Использовать восстановление из бэкапа (Решение 4), где бэкап сделан с другой конфигурацией портов.

Как поменять regport (systemd):

# Для 8.3.27.1989, instance default
sudo systemctl edit srv1cv8-8.3.27.1989@default.service

В открывшемся редакторе добавить (или дополнить секцию [Service]):

[Service]
Environment=SRV1CV8_REGPORT=1542

Перезапустить сервис. Учесть, что данные кластера хранятся в каталогах вида reg_<port> (например, reg_1541); при смене порта используется уже reg_1542 (и т.п. по документации вашей версии).

Плюсы: Гибкость при нескольких инстансах.
Минусы: Не решает циклическую зависимость «rmngr уже на regport → cluster insert на том же port» на одном экземпляре.

Решение 4: Восстановление из рабочей резервной копии reg_1541

Идея: Взять каталог reg_1541 (и при необходимости srvinfo и др.) с машины, где кластер уже корректно создан и есть worker с ClusterConfigService (например, 1c-server, 8.3.27.1786), и перенести их на проблемный сервер (1c-server-new, 1989).

Важно: Совместимость данных между 1786 и 1989 не гарантируется. Имеет смысл делать бэкап перед переносом и быть готовым к откату.

Шаги:

  1. Остановить сервисы 1С на 1c-server-new:
    bash lxc exec 1c-server-new -- systemctl stop srv1cv8-8.3.27.1989@default.service
  2. Создать резервную копию текущего reg_1541 на 1c-server-new (если есть что сохранять).
  3. Скопировать рабочий reg_1541 с 1c-server (1786) в 1c-server-new (например, через lxc file или общий каталог).
  4. Разложить файлы в /home/usr1cv8/.1cv8/1C/1cv8/reg_1541/ на 1c-server-new, выставить владельца usr1cv8.
  5. Запустить сервисы на 1c-server-new.
  6. Проверить:
    bash rac cluster list localhost:1545 rac server list --cluster=<UUID> localhost:1545

Если кластер виден и worker с ClusterConfigService есть, дальше можно регистрировать ИБ и пользоваться кластером. Если после переноса между разными версиями появятся ошибки — рассматривать GUI (Решение 1) или откат.

Плюсы: Можно быстро получить «уже настроенный» кластер без повторного rac cluster insert.
Минусы: Риск несовместимости версий; нужен рабочий донорский экземпляр.

Решение 5: Остановить srv1cv8 → очистить reg_1541/srvinfo → запустить только RAS → rac cluster insert → затем srv1cv8

Идея: Проверить, можно ли создать кластер через rac до запуска ragent (и, значит, до появления rmngr на 1541).

Ограничение: rac общается с RAS (порт 1545). Создание же кластера и размещение ClusterConfigService выполняются на стороне ragent (и rmngr). RAS выступает как «посредник» к ragent. Поэтому при остановленном ragent команда rac cluster insert либо не сможет создать кластер, либо создаст только запись в RAS без реального кластера на ragent. На практике для создания кластера ragent должен быть запущен — и тогда снова поднимается rmngr и конфликт.

Вывод: Вариант «только RAS, без ragent, потом cluster insert» не решает проблему. Имеет смысл не тратить на него время.

Решение 6: Использовать версию 8.3.27.1786 вместо 1989

Идея: На 1c-server (1786) rac cluster insert выполняется успешно при тех же портах. Если нет жёсткой необходимости именно в 1989, можно поднимать кластер на 1786.

Шаги:

  • Разворачивать/использовать контейнер 1c-server с 8.3.27.1786.
  • Создавать кластер и регистрировать ИБ через rac по уже проверенной схеме (см. 1c-rac-syntax-summary.md, 1c-server-final-status.md).

Плюсы: Избежание известной проблемы с 1989.
Минусы: Нужна возможность работать на 1786.

Решение 7: Обращение в поддержку 1С

Идея: Официально зафиксировать проблему и получить рекомендации для 8.3.27.1989.

Что указать:

  • Версия: 8.3.27.1989.
  • Окружение: Linux, systemd, один экземпляр ragent с regport 1541.
  • Факт: при запуске ragent автоматически стартует rmngr на 1541; rac cluster insert --host=localhost --port=1541 --name=cluster1 localhost:1545 даёт ошибку «Запуск рабочего процесса не возможен из-за конфликта IP портов».
  • Уточнить: рекомендуемый способ создания первого кластера и первого рабочего сервера (с ClusterConfigService) при таком поведении, в т.ч. предпочтительность GUI vs rac.

Сводная таблица решений

Решение Сложность Надёжность Когда применять
1. GUI консоль Низкая Высокая Всегда, если есть доступ по GUI
2. rac cluster list Очень низкая Зависит от конфигурации Первая проверка перед любыми правками
3. Другой regport Средняя Не снимает конфликт insert на том же хосте Несколько инстансов, кастомная схема портов
4. Восстановление reg_1541 Средняя Средняя (риск несовместимости версий) Есть рабочий бэкап с 1c-server
5. Только RAS + cluster insert Низкая Не работает Не рекомендуется
6. Версия 1786 Низкая Высокая (по вашему опыту) Если допустимо использовать 1786
7. Поддержка 1С Низкая Зависит от ответа Когда нужны официальные указания

Рекомендуемый порядок действий

  1. Проверить rac cluster list localhost:1545 при работающих сервисах (Решение 2). Если кластер есть — использовать его.
  2. Если кластера нет и создание через rac по-прежнему падает с «конфликт портов»:
  3. Предпочтительно: создать кластер через GUI (Решение 1), затем при необходимости зарегистрировать ИБ через rac/скрипты.
  4. Альтернатива: при наличии рабочего 1c-server (1786) — либо использовать его (Решение 6), либо аккуратно попробовать восстановление reg_1541 (Решение 4).
  5. При необходимости зафиксировать проблему и получить ориентир по 1989 — обращение в поддержку 1С (Решение 7).

Связанные документы