В практике администрирования серверов 1С:Предприятие часто возникают ситуации, когда необходимо поддерживать работу нескольких версий платформы одновременно. Особую сложность представляют случаи, когда на одном современном Linux-сервере (например, Debian) запускаются как актуальные (8.3.25), так и устаревшие (8.3.9) кластеры серверов. Рассмотрим сложную техническую проблему, связанную с ошибкой привязки программной лицензии, которая возникает исключительно на старых версиях платформы.
Мы проанализируем ситуацию, когда лицензия активирована корректно, но спустя некоторое время кластер перестает ее видеть, выдавая ошибку привязки к оборудованию, при этом конфигурация сервера физически не менялась.
Рассмотрим исходные данные. На хосте под управлением Linux развернуто три независимых кластера серверов 1С разных версий (например, 8.3.9.2033, 8.3.11.3034 и 8.3.25.1546). Используется одна многопользовательская программная лицензия (файл .lic). Изначально все кластеры работают корректно, но через неопределенное время на старой версии (8.3.9) возникает ошибка:
Ошибка программного лицензирования.
Ошибка привязки программной лицензии к компьютеру: file:///var/1C/licenses/20250225133058.lic
После получения лицензии удалены:
Phys mem_0: 12592119808
DISK_1: Virtual disk Ver: 1.0 Size: 10737418240
DISK_0: Virtual disk Ver: 1.0 Size: 69793218560
В текущей конфигурации компьютера имеются:
DISK_0: Virtual disk Ver: 1.0 Size:
DISK_0: Virtual disk Ver: 1.0 Size:
Обратите внимание на ключевой момент в тексте ошибки: в секции "В текущей конфигурации компьютера имеются" параметры дисков определяются, но их размер (Size) отсутствует (пустое значение). Это критически важный диагностический признак.
Чтобы понять причину сбоя, разберем, как платформа 1С проверяет привязку программной лицензии. Файл лицензии содержит "слепок" аппаратных характеристик сервера на момент активации. При работе сервер 1С периодически опрашивает операционную систему, чтобы убедиться, что он запущен на том же оборудовании.
В операционных системах Linux платформа получает эту информацию не через WMI (как в Windows), а путем прямого чтении системных файлов и каталогов, таких как:
/proc/cpuinfo — информация о процессорах./proc/meminfo — информация о памяти./sys/block/ и /proc/partitions — информация о дисковой подсистеме.Проблема, которую мы рассматриваем, заключается в том, что процесс сервера 1С версии 8.3.9 в определенный момент времени не может прочитать атрибуты устройства, в частности размер диска. При этом сама операционная система работает штатно, и более новые версии платформы (8.3.25) проблем не испытывают.
Проанализируем факторы, которые приводят к такому поведению именно на устаревших версиях платформы 1С, запущенных в среде современного Linux.
Современные дистрибутивы Linux (включая актуальные версии Debian, Ubuntu, CentOS) существенно ужесточили политики безопасности по сравнению с теми версиями ОС, которые были актуальны во времена выхода платформы 8.3.9.
Сервер 1С обычно работает от имени пользователя usr1cv8. Механизмы udev (управление устройствами) и systemd (система инициализации) могут ограничивать доступ непривилегированных пользователей к чтению детальных атрибутов блочных устройств в /sys или /proc.
Новые версии платформы (8.3.25) разработаны с учетом этих изменений и используют актуальные API или методы доступа. Старая версия 8.3.9 пытается обратиться к файлам по устаревшим путям или методам, и при малейшем изменении прав доступа или задержке ответа получает пустую строку вместо размера диска.
Если серверы 1С запущены как службы systemd, для них могут действовать параметры изоляции. Рассмотрим параметры конфигурации юнита службы:
PrivateDevices=yesPrivateTmp=yesProtectSystem=fullЭти параметры создают для процесса изолированное представление файловой системы. Если в конфигурации службы для 8.3.9 включены подобные ограничения (или они включены по умолчанию в новой версии ОС), старая платформа может видеть "виртуальные" устройства /dev, но не иметь возможности прочитать их реальные физические характеристики. Это объясняет строку DISK_0: Virtual disk Ver: 1.0 Size: с пустым размером.
В виртуальных средах нагрузка на дисковую подсистему может быть неравномерной. Старые версии платформы часто имеют жестко заданные, короткие тайм-ауты на ожидание ответа от системных вызовов.
Если в момент проверки лицензии дисковая подсистема нагружена (например, соседний кластер 8.3.25 выполняет тяжелый запрос), системный вызов чтения размера диска может не успеть вернуть данные. Новая платформа сделает повторную попытку (retry), а старая 8.3.9 может интерпретировать задержку как отсутствие данных и вернуть пустой результат, что немедленно приводит к ошибке лицензирования.
Давайте обратим внимание на важное различие в структуре файла 1CV8Clst.lst (список баз кластера) между версиями.
Версия 8.3.25:
...;DBUID=postgres;LIC=4380932628941686435;LicDstr=Y;...
Версия 8.3.9:
...;DBUID=postgres;Descr=;LicDstr=Y;...
Заметим, что в новой версии присутствует параметр LIC=.... Этот параметр позволяет "запоминать" (кэшировать), какая именно лицензия используется для конкретной информационной базы. Это оптимизирует процесс проверки и снижает частоту полных сканирований оборудования.
В версии 8.3.9 этого параметра нет. Это означает, что старая платформа вынуждена проводить полный цикл поиска и валидации лицензии значительно чаще (фактически при каждом запуске сеанса или регламентном действии). Частые проверки в сочетании с нестабильным доступом к /proc (описанным выше) многократно повышают вероятность того, что именно старый кластер "поймает" ошибку чтения оборудования.
Поскольку проблема кроется в несовместимости устаревшего бинарного кода 1С с современным окружением Linux, стандартные методы "переактивации" помогают лишь временно. Рассмотрим системные пути решения.
Наиболее надежный способ для старых платформ. USB-ключи используют другой механизм проверки (через драйвер HASP и менеджер лицензий), который менее чувствителен к изменениям в системных API файловой системы Linux, чем программные лицензии.
Если необходимо использовать именно версию 8.3.9, рекомендуется запускать её не на "голом" современном хосте рядом с новыми версиями, а в изолированном окружении, эмулирующем старую ОС.
Мы можем использовать Docker-контейнеры или LXC, где базовым образом будет выступать старая версия OS (например, Debian 8 или 9), соответствующая времени выпуска платформы 8.3.9. В таком контейнере системные библиотеки и ядро будут вести себя предсказуемо для старой платформы.
Если вы запускаете 8.3.9 через systemd, проверим файл юнита службы (обычно лежит в /etc/systemd/system/srv1cv83.service или аналогичном). Попробуем отключить изоляцию устройств, добавив или изменив параметры в секции [Service]:
[Service]
PrivateDevices=no
ProtectKernelTunables=no
ProtectControlGroups=no
После изменения необходимо выполнить systemctl daemon-reload и перезапустить службу. Это может дать процессу rphost прямой доступ к устройствам, необходимый для корректного чтения размера диска.
Самый радикальный, но правильный путь. Версия 8.3.9 является устаревшей и снятой с поддержки. Ошибки взаимодействия с новыми ядрами Linux в ней исправляться не будут. Если конфигурация позволяет, необходимо перевести базы на версию платформы не ниже 8.3.20, где механизмы работы с программными лицензиями в Linux значительно улучшены.
Ошибка "Size: [Empty]" в тексте сообщения о сбое лицензии на Linux однозначно указывает на проблему взаимодействия процесса сервера 1С с операционной системой при опросе оборудования. Старая платформа не получает данные о диске из-за прав доступа, тайм-аутов или изменившихся интерфейсов ядра. Решением является либо изоляция старой платформы в соответствующее ей окружение, либо обновление до актуальной версии.