我最初在 StackOverflow 上問過這個問題，但我認為這不是應用程式開發問題。基本上，我有一個 C++ 應用程序，它使用 msodbcsql17 套件連接到 SQL Server。它運行在RedHat 7 Linux伺服器上。將此應用程式部署到新環境時，本機管理員使用 yum 安裝了最新的可用 msodbcsql17 軟體包，即 17.6.1.1-1。我們的應用程式在連接到資料庫時掛起，systemctl 無法阻止它，只能在一段時間後殺死它。我檢查了我們的實驗室，應用程式在 msodbcsql17 版本 17.4.2.1.1-1 上運作良好。因此，我透過使用我們的一台實驗室伺服器進行版本測試，克隆它，並驗證應用程式在兩台伺服器上都運作良好。我將其中一台伺服器升級到 17.6 版本的 msodbcsql17，應用程式「按預期」損壞。所以我把它降級到17.4版本，應用程式仍然損壞。
據我所知，兩台伺服器上安裝的二進位（/opt/microsoft 資料夾中的所有內容）是相同的。除此之外，我只能看到 /usr/lib64 中的一個符號鏈接，它指向 /opt/microsoft 中的 SO 檔案。根據 yum 的說法，沒有安裝或刪除其他依賴項，我透過將「已安裝的 yum 清單」匯出到檔案並透過 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 是二進制的，但大小不同，我手動複製了這個文件，但沒有解決。
所以我不確定到底是什麼解決了這裡的問題。最有趣的部分：如果我將 /etc 資料夾與安裝的最新 msodbcsql17 進行 rsync，則該應用程式將再次開始工作。那麼幾乎就像 /etc 資料夾中出現了什麼問題？
答案1
好吧，經過一些更廣泛的檢查，我似乎錯過了第一個：odbcinst.ini 實際上是不同的！在 17.6 msodbc 安裝期間，刪除了一行。再次添加後，立即開始工作：
為什麼這條線被刪除了，我不知道。或者，在全新安裝的情況下，此行從未添加到 odbcinst.ini 中。無論如何，現在可以了。