Ошибки на клиенте при работе с сервером 1С на Linux. Часть 2

Администраторы и пользователи при работе в сервером 1C установленном на Linux часто сталкиваются с ошибками которые не встречаются на ОС MS Wndows. Связано это с тем что первоначально программа 1С Предприятие долгое время была ориентированна только на работу с ОС Windows и ее портировании на ОС Linux началось сравнительно недавно. Из-за особенностей архитектуры операционной системы Linux, некоторые моменты, которые под ОС Windows были само собой разумеющимися и не вызывали вопросов, тут требуют определенной настройки. Рассмотрим наиболее часто встречающиеся ошибки при работе клиентов с сервером на ОС Linux.

Оглавление:

Ошибка загрузки библиотеки libfontconfig.so

Пример полного текста ошибки:

Описание:

Не запускается база в режиме 1С:Предприятия.

Решение:

Установим недостающие пакеты:

Не печатается документ с штрихкодом. Ошибка (EObjectNotFound)

Пример полного текста ошибки:

Описание:

Не печатается документ с штрихкодом. Текст ошибки может быть связан с получением отраслевой лицензии(для отраслевых конфигураций).

Решение:

Установим недостающие пакеты(в нашем случае нужна была только libpng12):

Проблема с кодировкой в загружаемом файле в 1С

Пример полного текста ошибки:

Пример вывода сообщения об ошибке в программе 1С:

А это пример некорректного отображения символов:

Описание:

При загрузке данных из файла символы преобразовываются некорректно.

Источник

Работа платформы 1С:Предприятие с КриптоПро в ОС Linux

В статье рассматриваются некоторые особенности работы КриптоПро в ОС Linux и взаимодействия платформы 1С:Предприятие с КриптоПро.

В настоящее время поддержка криптографии при работе на ОС Linux ограничена возможностью использования только КриптоПро (http://www.cryptopro.ru). Платформа 1С:Предприятие обращается к модулю криптографии при создании объекта МенеджерКриптографии. В конструкторе объекта МенеджерКриптографии второй параметр означает путь к библиотеке модуля криптографии, реализующий функциональность, необходимую платформе. Установленный модуль криптографии КриптоПро может содержать библиотеку libcapilite.so — тогда следует указать путь к этой библиотеке.

Однако, в текущих версиях КриптоПро библиотека libcapilite.so отсутствует. Разработчики КриптоПро разделили функциональность, изначально содержавшуюся в одной библиотеке, на несколько библиотек. К ним относятся: libcapi10.so, libcapi20.so, libcapiext.so. Для того, чтобы платформа 1С:Предприятие могла использовать библиотеку КриптоПро нужно выполнить команду по созданию одной библиотеки из нескольких.

gcc — shared — Wl , — soname , libcapi 10 . so . 3 . 6 . 1 , libcapi 20 . so . 3 . 6 . 1 — o libcapilite . so

Команда выполняется в каталоге lib/ia32 или lib/amd64 в зависимости от разрядности установленного модуля криптографии.

Для работы команды gcc может понадобиться дополнительная установка gcc из репозитория используемого дистрибутива Linux. Например, для CentOS это команда

yum install gcc

Запуск Firefox для работы с КриптоПро

Платформа 1С:Предприятие может работать с модулем криптографии на клиентской стороне через веб-клиент. Веб-клиент — это браузер, которому нужно установить дополнение — расширение для работы с криптографией. Пример можно посмотреть в демонстрационной конфигурации платформы 1С:Предприятие — в разделе Предприятие в панели действий есть кнопка «Установить расширение работы с криптографией».

В случае запуска браузера Firefox при обращении к объекту МенеджерКриптографии может произойти аварийный выход из браузера. При этом, если браузер был запущен из консоли, в консоли будут следующие сообщения:

Warning: Fatal Error:
_XmGetDefaultDisplay cannot be used prior to VendorS.Initialize, returns NULL
Warning: Urm__OpenHierarchy: Display not yet opened — Invalid URM code
Error: MrmOpenHierarchy failed: can’t open hierarchy.

Такое сообщение означает, что модуль криптографии КриптоПро попытался вызвать графическую функцию из библиотеки motif, в которой произошла ошибка.

Для обхода этой проблемы браузер можно запускать следующей командой

Источник

Ошибка загрузки библиотеки libWand.so по причине:Библиотека не обнаружена.

Платформа: 1С:Предприятие 8.3 (8.3.5.1119)

Ошибки:
———————————————————————————
Ошибка загрузки библиотеки libWand.so по причине:Библиотека не обнаружена.
Часть функций будет недоступна.
Обратитесь к разделу справочной системы «1С:Предприятие — Работа пользователя –
Особенности работы в Linux – Внешние библиотеки»

find /usr/lib/ -name «libMagickWand.so*» -print
показывает:
/usr/lib/libMagickWand.so.4
/usr/lib/libMagickWand.so.4.0.1

делаю жесткую ссылку результат ноль.

Экспериментирую, ставлю Сервер 1С Предприятия 64 битный.

пробую перед запуском:
find /usr/lib/ -name «libMagickWand.so*» -print
показывает:
/usr/lib/libMagickWand.so.4
/usr/lib/libMagickWand.so.4.0.1

аналогично, но клиент запускается и все работает.

Я начал сомневаться в своих умственных способностях.

Есть ли решение у данной проблемы, или как обычно 1С лишь бы продать и все, а дальше хоть огнем гори?
Узнаю про апгрейд с 32 битной на 64 битную, тут вообще мои математические способности умерли.
32 битная стоит 50600
64 битная стоит 84600
апгрейд стоит 43200, в чем подвох?

пишу в техподдержку 1С, мало того, что они отвечают неделями, так еще просят и рег.номер, скан копии рег.карточек и прочую лабуду. после предоставления пропали. Такого идиотизма не встеречал. причем когда покупали, нас обслуживает 2 компании по 7 и 8 версии, 8 сказали, что мы итс брали у других пусть они регистрируют. 7 прошу зарегистрировать они говорят у кого покупали пусть они и регистрируют. пишу в 1С, они вообще убивают меня в мозг — это не регистрируется, т.к. это дополнительное расширение. Причем ни одного конкретного решения до сих пор я не получил от них, все на уровне протрите монитор на сервере или посмотрите (меню «Справка — О программе»), как в консоли на сервере это сделать. )))

работаю плотно и с HP и Microsoft и c СISCO. Недавно приобрели HP Proliant DL360e Gen8 как раз под эту самую злосчастную 1С. На этапе внедрения вышел на материнской плате VGA выход не критично, но тут же из Амстердама за 3 дня прислали новую материнскую плату, на следующий день из ближайшего города, где есть сертифицированный специалист приехал человек и заменил ее. Домой покупал принтер лазерный цветной, возникла проблема захвата бумаги при печати. Тут же прислали транспортной компанией новый принтер этот забрали, он уже 2 года меня радует. Нужна документация, звонишь присылают на электронную почту. Здесь .

решил поставить 14.04.1 т.к. там реализована multiarch, 32 сервер

service srv1cv83 start

Starting 1C:Enterprise 8.3 server: -su: /opt/1C/v8.3/i386/ragent: Нет такого файла или каталога

Error: service failed to start!

хотя он там есть.

Вот теперь сижу и думаю, купить апгрейд до 64 бит, но он стоит 43200, за эти деньги можно купить microsoft windows server 2012 + 15-20 лицензий на подключение. Или найти костыль, но 1,5 месяца с бубном ничего не дали.
кто что посоветует?

предлагали разнести Сервер 1С установить на обычной рабочей станции а БД оставить на серваке, как-то не кашерно.
пересобрать 32 убунту с pae, тоже не лучшее решение.

Есть ли Линукс дистрибутив, который корректно поддерживает мульархитектуру и 1С с ним дружит?

Источник

Русские Блоги

Проблема загрузки динамической библиотеки Linux

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

Предположим, мы используем тензорный поток и помещаем две динамические библиотеки, libtensorflow.so и libtensorflow_framework.so, которые необходимо вызвать, в каталог того же уровня, что и наша программа.

Процедура проверки следующая:

#include
#include «c_api.h»

<
printf(“Hello from TensorFlow C library version %s\n”, TF_Version());
return 0;
>

Составление программы и результаты следующие:

Видно, что с компиляцией программы проблем нет, но при выполнении исполняемой программы появляются следующие результаты:

Программа сообщает, что не удалось загрузить динамическую библиотеку, используйте команду ldd, чтобы проверить:

Почему мы четко указываем путь к динамической библиотеке при компиляции, и при компиляции программы нет проблем, но она не обнаруживается при выполнении? Чтобы

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

2. Когда программа выполняется, программа по-прежнему возвращается к пути по умолчанию в системе, чтобы найти динамическую библиотеку, необходимую для запуска программы.

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

Решение состоит в том, чтобы использовать -Wl, -rpath путь к требуемой динамической библиотеке, чтобы сообщить программе, что если требуемая динамическая библиотека не может быть найдена в пути по умолчанию, она найдет динамическую библиотеку по текущему указанному пути. После изменения инструкций компиляции gcc результаты будут следующими:

Видно, что динамическая библиотека загружена успешно, программа успешно работает и проблема решена.

Источник

Выполняю установку, настройку, сопровождение серверов. Для уточнения деталей используйте форму обратной связи

В Linux исполняемые файлы можно условно разделить на две группы – те, которые содержат в себе весь код, необходимые для работы, и те, которым необходимы разделяемые библиотеки. Первые называют статически собранными бинарными файлами, вторые называют динамически собранными исполняемыми файлами.

Статически собранные программы характеризуются тем, что могут корректно функционировать в любых условиях, и не зависят от наличия или отсутствия разделяемых библиотек, что может оказаться полезным в ситуациях, когда возникают конфликты версий разделяемых библиотек, или когда системные библиотеки повреждены или недоступны (например во время восстановления операционной системы после серьезного сбоя). К недостаткам таких исполняемых файлов следует отнести то, что они имеют значительный размер и для обновления программы необходимо полностью заменить ее исполняемый файл – например, если несколько статически собранных программ, которые работают с архивами ZIP, содержат ошибку, то для исправления ошибки необходимо заменить все эти программы, что может быть затруднено (например, будет трудно точно установить, какие именно программы содержат ошибочный код и нуждаются в обновлении). Кроме того, статически собранные программы не умеют совместно использовать совпадающие участки кода, что ведет к излишнему расходу системных ресурсов.

Динамически собранные исполняемые файлы для корректной работы требуют наличия файлов разделяемых библиотек, и соответственно при их отсутствии/повреждении не могут корректно функционировать, но зато для обновления программы и исправления ошибки часто оказывается достаточным просто заменить соответствующую разделяемую библиотеку, после чего ошибка исчезает во всех программах, которые эту библиотеку используют динамически. Динамически связанные программы также значительно меньше по объему, чем статически связанные, и код разделяемых библиотек может использоваться одновременно многими программами – что позволяет экономить системные ресурсы.

Подавляющее большинство программ в современных дистрибутивах Linux являются динамически собранными. Определить тип исполняемого файла (статический ли он либо с динамическим связыванием) можно, например, с помощью команды ldd:

# ldd /bin/su
linux-gate.so.1 => (0xb77d0000)
libpam.so.0 => /lib/libpam.so.0 (0xb77be000)
libpam_misc.so.0 => /lib/libpam_misc.so.0 (0xb77bb000)
libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb765f000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb765b000)
/lib/ld-linux.so.2 (0xb77d1000)

Но здесь нас подстерегает несколько НО:

1) Существует способ загрузки библиотек в обход ldd, функцией dlopen(). Такие библиотеки в выводе ldd не отображены.

2) Принцип работы ldd состоит в следующем: она устанавливает переменную окружения LD_TRACE_LOADED_OBJECTS, а затем запускает программу на исполнение. Входящий в libc загрузчик динамических библиотек (для GNU glibc это ld-linux.so) проверяет наличие этой переменной. Если она установлена, то вместо нормального запуска программы он выводит список используемых ею динамически подгружаемых библиотек и завершает работу.

То есть, мало того, что не все библиотеки (в идеале) мы сможем увидеть, так ещё и запускаем на исполнение файл! А если это руткит? Что же делать? Выход есть, правда не совсем удобный.

Выход первый (для пункта 2): использовать вместо ldd -> lddsafe (https://github.com/rg3/lddsafe) Скрипт использует objdump и безопасен, так как не запускает на исполнение проверяемую программу.

Выход второй (для пунктов 1 и 2): использовать команду strace. Правда вывод не такой удобный будет, как в случае с ldd.

Так же можно эту информацию получить и таким образом:

# readelf -d /sbin/fsck / grep ‘NEEDED’
0x00000001 (NEEDED) Shared library: [libblkid.so.1]
0x00000001 (NEEDED) Shared library: [libc.so.6]

Для более детальной вычинки бинарника можно использовать утилиту objdump и strace.

Что же делать, если вы получаете сообщения такого плана:

error while loading shared libraries: xxxx.so.0
cannot open shared object file no such file or directory

Это значит, что нет подходящих библиотек. Но что делать, если они есть, а система их не находит? На помощь приходит утилита ldconfig, которая управляет динамическими библиотеками.

С помощью этой программы вы можете добавить свои библиотеки, просматривать кеш библиотек. Список подключаемых библиотек находится в файле /etc/ld.so.conf, а кеш (собственно откуда берут информацию /lib/ld-linux.so) — /etc/ld.so.cache.

— Посмотреть список библиотек

# ldconfig -p | grep mysql
libmysqlclient_r.so.15 (libc6) => /usr/lib/libmysqlclient_r.so.15
libmysqlclient.so.15 (libc6) => /usr/lib/libmysqlclient.so.15

Подробнее можно узнать в справочном руководстве.

Так же можно использовать переменную окружения LD_LIBRARY_PATH.

Примечание.

В Solaris это можно сделать командой dtrace. Кстати, есть хорошая новость — её пытаются портировать на Linux.

Во FreeBSD используется команда truss

Источник