Проблемы с RedHat 7 msodbcsql17

Сначала я спросил об этом на StackOverflow, но, на мой взгляд, это не проблема разработки приложений. По сути, у меня есть приложение на C ++, которое подключается к SQL Server с помощью пакета msodbcsql17. Он работает на сервере Linux RedHat 7. При развертывании этого приложения в новой среде локальные администраторы установили последний доступный пакет msodbcsql17 с yum,что 17.6.1.1-1. Наше приложение зависает при подключении к БД, systemctl не может его остановить, только убивая через некоторое время. Я проверил в нашей лаборатории, приложение отлично работает с msodbcsql17 версии 17.4.2.1.1-1. Поэтому я протестировал версии, взяв один из наших лабораторных серверов, клонировав его и убедившись, что приложение работает нормально на обоих. Я обновил один из серверов до версии msodbcsql17 17.6, приложение сломалось «как и ожидалось». Поэтому я понизил его до версии 17.4, но приложение все еще не работает.

Насколько я могу судить, установленные двоичные файлы (все в папке / opt / microsoft) одинаковы на двух серверах. Помимо этого, я вижу только одну символическую ссылку из / usr / lib64, которая указывает на файл SO в / opt / microsoft. Согласно yum, никакие другие зависимости не были установлены или удалены, я проверил это, экспортировав «yum list installed» в файл и сравнив их по diff.

Я попытался использовать rsync для копирования файлов с исходного рабочего сервера на новый сервер. Сначала я просто сделал пробный прогон, но не обнаружил никакой разницы. Поэтому я скопировал всю папку / usr, но все еще не работал. Затем я скопировал всю папку / etc с помощью rsync, я изменил имя хоста и конфигурацию IP (очевидно, эти файлы также были перезаписаны), и приложение снова начало работать. Поэтому я снова сломал его, установив последнюю версию msodbcsql17, удалив ее и установив предыдущую версию, а также выполнил еще один пробный запуск rsync. В папке usr никаких различий, rsync только записывает, что пропускает символические ссылки (пропускает нестандартный файл "tmp"). Однако в папке etc было несколько отличий, и, хоть убей, я не могу понять, какой здесь проблемный файл:

sudo rsync -r --dry-run --out-format="[%t]:%o:%f:Last Modified %M" root@X.X.X.X:/etc/ /etc/ | less

[2020/12/16 00:59:54]:recv:hostname:Last Modified 2019/11/07-17:10:40
[2020/12/16 00:59:54]:recv:ld.so.cache:Last Modified 2020/12/16-00:40:20
[2020/12/16 00:59:54]:recv:odbcinst.ini:Last Modified 2019/11/27-17:03:27
[2020/12/16 00:59:54]:recv:sysconfig/network-scripts/ifcfg-ens160:Last Modified 2019/11/07-17:09:02
[2020/12/16 00:59:54]:recv:tuned/active_profile:Last Modified 2020/09/15-09:51:08
[2020/12/16 00:59:54]:recv:tuned/profile_mode:Last Modified 2020/09/15-09:51:08

/ etc / hostname и / etc / sysconfig / network-scripts / ifcfg-ens160 очевидно разные. /etc/odbcinst.ini был регенерирован во время установки msodbcsql17, но содержимое такое же, как указано в diff. Что касается остального, опять же, содержимое такое же, согласно diff. Ну, за исключением ld.so.cache, который является двоичным, но имеет другой размер, я скопировал этот файл вручную, и это не помогло.

Итак, я ' Я не уверен, что именно здесь решает проблему. Самое интересное: если я синхронизирую папку / etc с последней установленной версией msodbcsql17, приложение снова начинает работать. Значит, в папке / etc что-то ломается?

0
задан 16 December 2020 в 02:18
1 ответ

Хорошо, после более тщательной проверки я, кажется, пропустил самое первое: odbcinst.ini на самом деле другой! Во время установки msodbc версии 17.6 была удалена одна строка. После повторного добавления сразу заработало:

odbcinst.ini

Зачем убрали эту строчку, не знаю. Или, в случае новой установки, эта строка никогда не добавлялась в odbcinst.ini. Во всяком случае, теперь это работает.

0
ответ дан 16 December 2020 в 18:11

Теги

Похожие вопросы