Как исправить ошибку загрузки компоненты liccspr в 1С:Предприятии?

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

При обновлении платформы 1С:Предприятие на версии ветки 8.3.22 и выше (например, 8.3.22.1923), многие системные администраторы сталкиваются с появлением в технологическом журнале (ТЖ) пугающих записей: LoadComponent(liccspr): Ошибка загрузки компоненты liccspr. Часто эта ошибка сопровождается существенным замедлением работы базы, некорректной работой сервисов ЭДО и внезапными завершениями рабочих процессов rphost. В этой статье мы подробно разберем, что это за компонента, насколько она критична и как привести систему в стабильное состояние.

Выясним причину: что такое компонента liccspr?

Для начала проанализируем природу данной компоненты. Аббревиатура liccspr расшифровывается как Licensing Center Client Shared PRocedures. Это специализированный кросс-платформенный модуль, который отвечает за взаимодействие платформы с Центром Лицензирования 1С. Он используется для проверки программных лицензий, работы с облачными подписками и сервисами ИТС.

Рассмотрим, почему ошибка возникает именно в новых версиях платформы. Начиная с релизов 8.3.22, разработчики изменили алгоритм опроса доступных систем лицензирования. Теперь платформа пытается загрузить эту компоненту при старте каждого рабочего процесса rphost «на всякий случай», даже если ваша конфигурация использует аппаратные ключи HASP или локальные файлы лицензий, которым этот модуль не требуется. Если файл компоненты отсутствует в каталоге установки (что часто бывает в стандартных поставках под Linux или при специфических обновлениях), генерируется исключение EXCP.

Официальная позиция и реальное влияние на работу

Проанализируем ответ линии консультаций 1С, который получили пользователи: данное сообщение признано «косметическим дефектом». Согласно официальной версии, отсутствие этой компоненты не должно влиять на стабильность работы сервера. Однако практика показывает обратное: в момент возникновения ошибки в ТЖ часто фиксируются записи о неисправимых ошибках сервера и аварийном завершении приложения.

Выясним, почему это происходит. Постоянные неудачные попытки загрузки модуля создают микро-задержки и избыточную нагрузку на дисковую подсистему из-за разрастания логов технологического журнала. Если сервер нагружен, тысячи таких обращений в минуту могут привести к деградации производительности.

Решение 1: Проверка и перезапуск службы лицензирования

Рассмотрим ситуацию, когда ошибка сопровождается «тупой» работой 1С. Часто корень проблемы кроется не в самой компоненте liccspr, а в зависших процессах сервера лицензирования. Если в вашей сети используется выделенный сервер лицензирования, выполним следующие шаги:

  1. Откроем консоль администрирования кластера 1С.
  2. Проверим список процессов в разделе «Серверы лицензирования».
  3. Если обнаружены неактивные или «зомби» процессы, необходимо выполнить перезапуск службы.

В операционных системах Linux (Ubuntu, Astra Linux) выполним команду перезапуска службы менеджера лицензий:

systemctl restart haspd

Или, если используется программное лицензирование, перезапустим службу сервера 1С:

systemctl restart srv1cv83

Решение 2: Настройка фильтрации технологического журнала

Чтобы ошибка не «забивала» логи и не тратила ресурсы сервера на запись бесполезной информации, мы можем исключить её из выгрузки ТЖ. Разберем, как это сделать через файл logcfg.xml. Нам нужно добавить условие фильтрации для события EXCP, которое будет игнорировать описание, содержащее текст «liccspr».

Пример настройки секции в logcfg.xml:


<log location="/var/log/1c/logs" history="72">
    <event>
        <eq property="Name" value="EXCP"/>
        <ne property="Descr" value="*liccspr*"/>
    </event>
    <property name="all"/>
</log>

Используя оператор ne (not equal) с маской *liccspr*, мы указываем системе не записывать данные исключения в лог. Это снизит нагрузку на IOPS и позволит сфокусироваться на действительно важных ошибках.

Решение 3: Устранение зависимостей в среде Linux

Если вы работаете на Ubuntu или Astra Linux, проанализируем системные зависимости. Компонента liccspr может требовать специфические библиотеки OpenSSL или Kerberos. Проверьте наличие установленных пакетов:

  1. libcom_err.so.2
  2. libkrb5.so.3
  3. OpenSSL 1.1 (Важно: платформы 8.3.22 некорректно работают с OpenSSL 3.0, которая установлена в Ubuntu 22.04 по умолчанию).

Также проверим права доступа. Убедимся, что пользователь, под которым запущен сервер (обычно usr1cv8), имеет права на чтение и выполнение во всем каталоге /opt/1cv8/x86_64/.... Недостаток прав часто приводит к тому, что платформа «не видит» модуль, даже если он физически присутствует на диске.

Решение 4: Откат на стабильную версию платформы

В случаях, когда стабильность работы критична (например, в базах 1С:Документооборот или ERP), а косметическая ошибка сопровождается постоянными вылетами, рассмотрим вариант даунгрейда. Как показывает опыт многих администраторов, переход на ветку 8.3.21 решает проблему.

Рекомендуемые стабильные релизы, где данная ошибка не приводит к краху процессов:

Перед откатом обязательно выполните тестирование на копии базы, так как новые релизы конфигураций (например, последние версии «1С:Розница») могут требовать функционал именно 22-й платформы.

Резюме

Подводя итог, отметим: сама по себе строка Ошибка загрузки компоненты liccspr — это чаще всего лишь «шум» в логах. Однако, если она сопровождается падением rphost, истинную причину стоит искать в событиях SDBL (запросы к СУБД) или MEM (утечки памяти), которые идут в ТЖ сразу после этого сообщения. Компонента liccspr лишь «подсвечивает» момент инициализации процесса, который может прерываться из-за более глубоких проблем с лицензированием или системными библиотеками.

← На главную