При переходе на импортонезависимые решения системные администраторы часто сталкиваются с нетипичным поведением серверной части 1С на операционных системах семейства Linux. Одной из самых неприятных проблем является ситуация, когда при попытке входа одного пользователя сервер начинает генерировать десятки фантомных сеансов, после чего работа аварийно завершается с сообщением "Недостаточно лицензий". Рассмотрим подробнее, почему это происходит и как стабилизировать работу системы.
Проанализируем ситуацию: при использовании платформы 1С (особенно версии 8.3.11) в связке с ОС Ubuntu 17 и СУБД PostgreSQL наблюдается странный эффект. Сразу после авторизации пользователя программа "зависает" на несколько минут. В консоли администрирования кластера 1С при этом видно, что каждые 2–3 секунды создается новый сеанс. Система пытается инициализировать рабочее окружение, но из-за внутреннего сбоя в модуле лицензирования процесс обрывается, не закрывая текущую сессию, и инициирует новую попытку.
Это происходит до тех пор, пока количество открытых (хоть и нерабочих) сеансов не исчерпает доступный пул клиентских лицензий. Как только лимит достигнут, менеджер лицензий выдает финальную ошибку, и доступ блокируется полностью. Выясним основные причины такого поведения.
Одной из наиболее вероятных причин является зарегистрированная ошибка программного лицензирования в среде Linux, работающей в виртуальном окружении (KVM, VMware). Модуль защиты 1С при проверке привязки лицензии к "железу" пытается обратиться к файлу /sys/block/vda/device/model (или аналогичному для устройств sda). В некоторых дистрибутивах Linux или при определенных настройках гипервизора доступ к этому пути ограничен или файл отсутствует. Это вызывает крах подсистемы лицензирования. Платформа 8.3.11 оказалась особенно чувствительна к этому фактору.
Разберем технологические изменения: начиная с версии 8.3.11, компания 1С существенно ужесточила механизмы проверки лицензий для Linux-серверов. Если в более ранних версиях (8.3.10 и ниже) существовала возможность работы до 10–12 пользователей без явной установки серверного ключа (так называемый "тестовый период" или особенность сборки), то в новых релизах этот функционал был пересмотрен. Теперь при малейшем несоответствии параметров лицензии или параметров оборудования сервер прерывает сеанс.
Как показала практика, наиболее быстрым и эффективным способом решения проблемы является использование версии платформы, предшествующей глобальным изменениям в системе защиты. Разберем шаги по исправлению ситуации:
8.3.10.2466). Эта версия корректно работает с программными лицензиями в Linux и не имеет бага зацикливания сеансов.srv1cv83 и проверим статус лицензий в консоли администрирования.Если специфика вашей конфигурации (например, современные версии "1С:Бухгалтерии") требует более свежей платформы, следует перепрыгнуть проблемную ветку 8.3.11. Посмотрим на рекомендации:
/sys/block/vda был исправлен разработчиками.Помимо выбора версии платформы, для стабильной работы 1С на Linux необходимо выполнить тонкую настройку ОС. Проанализируем ключевые моменты:
1. Выбор версии ОС. Не рекомендуется использовать промежуточные версии Ubuntu (17.04, 19.10 и т.д.). Для серверов 1С подходят только LTS-релизы (Long Term Support), такие как 16.04, 18.04 или 20.04. В них пакетная база и системные библиотеки (glibc) более стабильны и предсказуемы.
2. Настройка лимитов (ulimit). Сервер 1С на Linux активно работает с файлами сеансов и лицензий. Если лимит на количество открытых файлов слишком мал, система начнет выдавать ошибки. Отредактируем файл /etc/security/limits.conf, добавив строки:
usr1cv8 soft nofile 65536
usr1cv8 hard nofile 65536
3. Отключение IPv6. Часто задержки при проверке лицензий (те самые 5 минут зависания) связаны с попытками системы разрешить имена через IPv6. Рекомендуется принудительно отключить этот протокол в параметрах ядра sysctl.conf.
4. Блокировка регламентных заданий. Чтобы исключить влияние фоновых процессов на этапе диагностики, временно включим блокировку регламентных заданий в свойствах информационной базы через консоль администрирования (1cv8-mgmt). Это поможет понять, создаются ли лишние сеансы самим пользователем или автоматическими службами платформы.
Если вы используете СУБД от PostgresPro (специальная сборка для 1С), убедитесь, что параметры max_connections в файле postgresql.conf установлены с запасом. Если сервер 1С начнет "штамповать" сеансы, он может быстро забить все соединения к базе данных, что приведет к каскадному падению всего кластера. Оптимальное значение должно быть как минимум в 2–3 раза больше предполагаемого количества пользователей 1С.
Резюме: Если вы столкнулись с "кучей запущенных сеансов" на Ubuntu, в первую очередь проверьте версию платформы. Откат на 8.3.10 или переход на 8.3.12+ в сочетании с использованием LTS-дистрибутива Ubuntu решит проблему лицензирования и обеспечит стабильную работу системы.