В процессе разработки и администрирования систем на платформе 1С:Предприятие 8.3 специалисты часто сталкиваются с ситуацией, когда одна и та же функция — СтрокаСоединенияИнформационнойБазы() — возвращает разные значения в зависимости от контекста выполнения. Особенно критично это проявляется в регламентных заданиях. В то время как у пользователя в сеансе функция корректно возвращает сетевое имя сервера (например, Srvr="servername";Ref="base";), при выполнении того же кода на сервере в рамках фонового задания результатом становится Srvr="localhost";Ref="base";. Это может привести к сбоям в работе внешних систем, интеграций или при попытке программного подключения к этой же базе из кода регламентного задания.
В этой статье мы подробно разберем, почему сервер «считает» себя локалхостом, и пошагово проанализируем методы исправления этой ситуации.
Для начала выясним, откуда платформа берет данные для формирования строки соединения. Когда функция СтрокаСоединенияИнформационнойБазы() вызывается на стороне клиента, она использует параметры, указанные в списке общих информационных баз в окне запуска (в файле ibases.v8i). Если там прописано сетевое имя servername, клиент его и видит.
Однако регламентное задание выполняется в процессе rphost на стороне сервера. В этом контексте клиентского приложения (и его настроек запуска) просто не существует. Процесс rphost обращается к менеджеру кластера (rmngr), чтобы получить информацию о текущей базе. Если при создании кластера или регистрации рабочего сервера в консоли администрирования 1С в качестве имени компьютера было указано localhost, то именно это значение будет «зашито» во внутренние идентификаторы кластера. Рассмотрим, как это исправить.
Это самый радикальный и эффективный метод. Параметры кластера хранятся в текстовых файлах формата .lst в каталоге данных сервера (обычно это srvinfo). Если изменение через консоль администрирования не помогает, необходимо внести правки вручную.
Важно: перед выполнением любых действий с файлами конфигурации обязательно создайте резервную копию папки srvinfo!
Выполним следующие шаги:
services.msc).C:\Program Files\1cv8\srvinfo.srvinfo найдем файл clusters.lst. Проанализируем его содержимое. Если в описании кластера фигурирует localhost, заменим его на реальное сетевое имя сервера или его FQDN (например, server-dc01.domain.local).reg_1541).1CV8Clst.lst. Это основной файл настроек кластера. Откроем его текстовым редактором и выполним поиск по слову localhost. Заменим все вхождения на корректное имя сервера.srvinfo и перейдем в папку 1540 (или другой порт менеджера). Найдем файл 1cv8wsrv.lst и проделаем аналогичную операцию замены.После перезапуска сервер перечитает настройки, и функция СтрокаСоединенияИнформационнойБазы() в регламентных заданиях начнет возвращать корректное имя.
Посмотрим на ситуацию со стороны консоли администрирования. Часто администраторы меняют имя сервера СУБД, но забывают про свойства самого рабочего сервера 1С.
Проанализируем дерево объектов в консоли:
Кластеры -> [Имя кластера] -> Рабочие серверы.localhost, это и есть корень проблемы.Если поле «Адрес» недоступно для редактирования или изменения не сохраняются, может потребоваться удаление рабочего сервера из списка и добавление его заново по правильному имени. Будьте осторожны: это может потребовать перенастройки распределения нагрузки, если у вас многосерверный кластер.
Иногда имя хоста может быть принудительно задано в параметрах запуска самой службы агента сервера. Рассмотрим, как это проверить:
Win + R, введем regedit.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent.ImagePath.-regport и связанных с ним параметров. Хотя обычно имя сервера там не указывается напрямую, некорректные настройки путей к -d (каталогу данных) могут приводить к тому, что сервер подхватывает настройки «по умолчанию», где прописан localhost.Выясним, как операционная система разрешает имена. Если в системе активен IPv6, 1С может сопоставлять локальное имя с адресом ::1, что интерпретируется как localhost.
Проанализируем файл hosts по адресу C:\Windows\System32\drivers\etc\hosts. Убедимся, что там нет жестких привязок сетевого имени сервера к адресу 127.0.0.1. Рекомендуется явно прописать:
192.168.1.10 servername
Где 192.168.1.10 — реальный IP-адрес сервера в локальной сети.
После проведения вышеописанных манипуляций крайне желательно очистить серверный кэш метаданных, так как старые параметры соединения могут быть кэшированы в сеансовых данных. Для этого при остановленной службе сервера 1С необходимо:
srvinfo (например, srvinfo\reg_1541\UUID_вашей_базы).snccntx.Рассмотрим пример кода, который поможет вам проверить результат исправлений в Журнале Регистрации без запуска клиента:
Процедура ПроверитьСтрокуСоединения() Экспорт
ТекСтрока = СтрокаСоединенияИнформационнойБазы();
ЗаписьЖурналаРегистрации("ПроверкаСоединения",
УровеньЖурналаРегистрации.Информация, , ,
"Текущая строка соединения на сервере: " + ТекСтрока);
КонецПроцедуры
Запустите это действие через консоль заданий или создайте временное регламентное задание. Если после всех правок в журнале регистрации вы увидите Srvr="servername" вместо localhost, значит, задача успешно решена.
Подводя итог, можно сказать, что проблема «локалхоста» в 1С — это всегда следствие того, как именно сервер был зарегистрирован в кластере в момент установки или первой настройки. Использование сетевых имен вместо localhost и 127.0.0.1 на всех этапах настройки — лучший способ избежать подобных несоответствий в будущем.