我最初在 StackOverflow 上问过这个问题，但在我看来这不是应用程序开发问题。基本上，我有一个使用 msodbcsql17 包连接到 SQL Server 的 C++ 应用程序。它在 RedHat 7 Linux 服务器上运行。在将此应用程序部署到新环境时，本地管理员使用 yum 安装了最新可用的 msodbcsql17 包，即 17.6.1.1-1。我们的应用程序在连接到数据库时挂起，systemctl 无法停止它，只能在一段时间后将其杀死。我在我们的实验室中检查过，应用程序在 msodbcsql17 版本 17.4.2.1.1-1 下运行良好。因此，我通过获取我们的一台实验室服务器、克隆它并验证应用程序在两台服务器上都运行良好来测试版本。我将其中一台服务器升级到 msodbcsql17 的 17.6 版本，应用程序“如预期”一样崩溃了。所以我将其降级到 17.4 版本，但应用程序仍然崩溃了。
据我所知，两台服务器上安装的二进制文件（/opt/microsoft 文件夹中的所有内容）是相同的。除此之外，我只能看到 /usr/lib64 中的一个符号链接，它指向 /opt/microsoft 中的一个 SO 文件。根据 yum，没有安装或删除其他依赖项，我通过将“yum list installed”导出到文件并通过 diff 进行比较来检查这一点。
因此，我尝试使用 rsync 将文件从原始工作服务器复制到新服务器。我首先只是进行了试运行，但没有发现任何差异。因此，我复制了整个 /usr 文件夹，但仍然不起作用。然后，我使用 rsync 复制了整个 /etc 文件夹，我改回了主机名和 IP 配置（显然这些文件也被覆盖了），应用程序又开始工作了。因此，我再次通过安装最新版本的 msodbcsql17、删除它并安装以前的版本来打破它，然后进行了另一次 rsync 试运行。在 usr 文件夹中，没有差异，rsync 仅记录它正在跳过符号链接（跳过非常规文件“tmp”）。然而，在 etc 文件夹中有一些差异，就我而言，我看不出这里有问题的文件是什么：
sudo rsync -r --dry-run --out-format="[%t]:%o:%f:Last Modified %M" [email protected]:/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 是二进制文件，但大小不同，我手动复制了这个文件，但没有解决。
所以我不确定到底是什么解决了这个问题。最有趣的部分是：如果我使用最新的 msodbcsql17 rsync /etc 文件夹，应用程序将重新开始工作。所以几乎就像 /etc 文件夹中有什么东西坏了？
答案1
好吧，经过一些更广泛的检查，我似乎错过了第一个：odbcinst.ini 实际上不同！在 17.6 msodbc 安装期间，删除了一行。再次添加后，它立即开始工作：
我不知道为什么删除了这一行。或者，在全新安装的情况下，这一行从未添加到 odbcinst.ini 中。无论如何，它现在可以正常工作了。