Устранение ошибки "libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported" при запуске 1С на Debian 13.
При попытке запуска на исполнение платформы 1с в среде debian 13.2 без возникает ошибка
"libsoup3 symbols detected. Using libsoup2 and libsoup3 in the same process is not supported."
Проверено на платформах версий:
8.3.27.1936
8.5.1.1150
Что, по-видимому, вызвано использованием в компонентах платформы различных версий библиотеки libsoup. Или для одного компонента указывается необходимая версия, а для другого без указания конкретной версии, и тогда используется наиболее старшая из доступных.
При установке Debian 13.2 одновременно установлены версии
libsoup-2.4
libsoup-3.0
Советы по удалению одной из версий приводят к нарушению целостности системы -- для работы системы нужны обе версии.
Чтобы устранить ошибку, необходимо заставить 1С использовать только одну из версий библиотеки libsoup.
Это можно сделать, создав символическую ссылку на выбранную основной версию.
Для моего случая (сочетания версий библиотек), посредством команды: sudo ln -s libsoup-3.0.so.0.7.4 libsoup-2.4.so.1
Скрипт bash для корректного обновления серверной части платформы 1С Предприятия
(сохраняет и восстанавливает настройки служб, даже если их несколько, изменяет версию платформы во всех веб-публикациях и делает еще много полезных мелочей не включенных в штатный инсталлятор)
Иными словами "обновление под ключ" или "нажал и забыл"
Исследуем, почему COPY и последующий rm оставляют установщик в слоях Docker. На Docker Engine 29.8.0 сравнила три сборки с фиктивным дистрибутивом: bind mount и отдельный завершающий этап исключили его слой. В статье — первичные размеры и границы проверки лицензирования 1С; в архиве — воспроизводитель и анализатор inspect/history.
Пошагово показываю, как на сервере 1С 8.3 под Linux получить PNG QR через HTTPСоединение без COM, сохранить ответ во временный файл или двоичные данные и вывести картинку на форме через временное хранилище. Разбираю замену XMLHTTP, кодирование текста, HTTPS и типичные ошибки «сервер недоступен».
Как запускать клиентские приложения 1С:Предприятие 8.3 на хосте Linux (KDE Plasma, Wayland или другое окружение) в rootless podman-контейнере, ничего не устанавливая в систему хоста.
Пятый выпуск нашего открытого инженерного сериала по построению отказоустойчивой инфраструктуры 1С на Linux!
В этой части мы спускаемся на уровень операционной системы и выполняем обещание, данное в Roadmap предыдущей статьи - разбираем физику подсистемы виртуальной памяти Linux, ликвидируем скрытые I/O-тормоза и публикуем новый прикладной инструмент для системных администраторов и DBA.
Системный анализ архитектурных границ масштабирования учетных систем «1С:Предприятие 8.3» под управлением PostgreSQL в ОС Linux. Формулирование инженерной методологии сквозного проекта «Торговый контур», определение измеримых целевых показателей (p95, MTTR, APDEX) и стратегии поэтапной модернизации эксплуатационного контура без остановки промышленных учетных процессов.
Декларативный pipeline в GitHub Actions, тонкости лицензирования в Docker (--net=host), изоляция RUN_ID и интеграция со сборочным конвейером SRE-Suite-for-1C-platform.
Вторая часть практического руководства (https://infostart.ru/public/2779597): от первого коммита до детерминированного синтаксического гейта на headless-раннере Linux
Столкнулся с той же проблемой на Ubuntu 24.04.
Предложенный трюк не понравился тем, что подменяется системная библиотека, которая может потребоваться другим приложениям.
Подробности
Решил подробно разобраться с вопросом. Проблема хорошо описана в статье
Summary
libsoup 3 is a new API version of libsoup that provides support for HTTP/2.
Unfortunately, it is incompatible with libsoup 2. To avoid misbehavior,
applications will crash on startup if linked to both libsoup 2 and libsoup 3
at the same time.
То есть, любое приложение, которое одновременно зависит от библиотек
libsoup-2 и libsoup-3 будет аварийно завершаться.
Получается, что 1cv8 косвенно зависит от библиотеки libwx_gtk3u-3.0.so.0,
которая в свою очередь непосредственно зависит от libsoup-2.4.so.1
и косвенно от libsoup-3.0.so.0. Подменив libsoup-2.4.so.1 библиотекой
libsoup-3.0.so.0 с помощью символической ссылки, мы решаем проблему.
По крайней мере в тех сценариях, которые мне встречались. Но кто знает,
может быть при каком-то сценарии в приложении всё же вызывается метод
из библиотеки libsoup-2.4.so.1.
Можно ли подменить библиотеку не на системном уровне, а локально,
например в папке, в которой расположен исполняемый файл 1cv8?
Раньше можно было. В Ubuntu 20.04 помогало выполнение команд
$ cd /opt/1cv8/x86_64/8.3.27.1859
$ sudo ln -s /lib/x86_64-linux-gnu/libsoup-3.0.so.0 libsoup-2.4.so.1
Почему это работало? Процесс поиска файла динамической библиотеки хорошо описан в статье
When executing a program, I guess its NEEDED libraries are loaded one by one,
and their NEEDED libraries are also loaded, in some breadth first manner,
as said in this SO post. It can be confirmed via multiple ways,
either by reading the ELF format yourself
or using external tools like ldd as shown in the previous SO post.
What happens when a new .so file is encountered (either directly or indirectly
needed by a program) This article from Debian wiki explains very well what happens
1. the DT_RPATH dynamic section attribute of the library causing the lookup
2. the DT_RPATH dynamic section attribute of the executable
3. the LD_LIBRARY_PATH environment variable, unless the executable is setuid/setgid.
4. the DT_RUNPATH dynamic section attribute of the executable
5. /etc/ld.so.cache
6. base library directories (/lib and /usr/lib)
DT_RPATH is just RPATH extracted by readelf -d.
Показать
Посмотрим, какие значения RPATH и RUNPATH у исполняемого файла и проблемной библиотки.
Как видим, в файле 1cv8 установлен только атрибут RUNPATH, равный $ORIGIN,
а в библиотеке ни RPATH, ни RUNPATH не установлены. $ORIGIN означает папку,
в которой находится проверяемый файл. В нашем случае для файла 1cv8 -
это папка /opt/1cv8/x86_64/8.3.27.1859.
Использование и различие между RPATH и RUNPATH хорошо описаны в ответе на вопрос в stackoverflow
Using the directories specified in the DT_RUNPATH dynamic
section attribute of the binary if present. Such directories
are searched only to find those objects required by DT_NEEDED
(direct dependencies) entries and do not apply to those
objects' children, which must themselves have their own
DT_RUNPATH entries. This is unlike DT_RPATH, which is applied
to searches for all children in the dependency tree
Таким образом, в нашем случае, при условии, что не установлена переменная
LD_LIBRARY_PATH, поиск файла библиотеки libsoup-2.4.so.1 будет выполняться
только в /etc/ld.so.cache и системных папках /lib и /usr/lib.
Если бы в библиотеке libwx_gtk3u-3.0.so.0 был установлен атрибут RUNPATH,
равный $ORIGIN, то поиск зависимых библиотек осуществлялся бы и в папке,
в которой находится файл libwx_gtk3u-3.0.so.0. В этом случае можно было бы
сделать подмену библиотеки libsoup-2.4.so.1 в папке /opt/1cv8/x86_64/8.3.27.1859,
как это было в Ubuntu 20.04.
Видимо, в Ubuntu 20.04 была ошибка, и атрибут RUNPATH трактовался как RPATH,
поэтому подмена в локальной папке работала. Но разработчики Ununtu, наверно,
исправили ошибку загрузчика динамических библиотек, и поэтому такой трюк теперь не проходит.
Пойдем тогда в другую сторону. Если наше приложение фактически не зависит от библиотеки libsoup-2.4.so.1, может быть её просто удалить из списка зависимостей? К счастью, такая возможность есть. К несчастью, при этом потребуется изменение существующих файлов в поставке 1С.
Подробности
Для начала найдем все исполняемые файлы и библиотеки, у которых есть зависимость от libsoup-2.4.so.1.
Оказалось, что там системная библиотека libwebkit2gtk-4.0.so.37 слинкована с libsoup-2.4.so.1, а не с libsoup-3.0.so.0, как в Ubuntu 24.04, поэтому там проблема не возникает.
В любом случае, удаляя зависимость от libsoup-2.4.so.1, оставляя только транзитивную зависимость от актуальной библиотеки libsoup через libwebkit2gtk-4.0.so.37, мы решаем исходную проблему независимо от версии ОС.
В Ubuntu 24.04 еще с одной проблемой столкнулся. При работе с внешней компонентой электронной подписи с использованием КриптоПро в неизолированном режиме падает сервер 1С:Предприятия (rphost), в изолированном - контейнер addnhost64. Текст ошибки в /var/log/syslog:
auth.c:143:IsClientAuthorized() Process 4321 (user: 1234) is NOT authorized for action: access_pcsc
Такой же текст ошибки можно увидеть, выполнив команду
$ systemctl status pcscd.service
Там же есть еще и предупреждение
pcscd.service: Referenced but unset environment variable evaluates to an empty string: PCSCD_ARGS
Поиск в гугл отправляет на багтрекер Ubuntu
Там рекомендуют создать отсутствующий в системе файл /etc/default/pcscd и добавить в него строчку
PCSCD_ARGS=--disable-polkit
Она отключает использование polkit в pcsc.
После этого компонента перестает падать.
1С поставляет библиотеки как для новых, так и для старых версий Linux. Установщик 1С:Предприятия в зависимости от версии Linux должен выбрать, какую библиотеку установить.
В моем случае было выполнено обновление ОС Ubuntu с 22.04 до 24.04 при уже установленном 1С:Предприятии, поэтому библиотеки остались старыми. Переустановка 1С:Предприятия должна помочь.
