Inicialmente pregunté esto en StackOverflow, pero en mi opinión no es un problema de desarrollo de aplicaciones. Básicamente, tengo una aplicación C++ que se conecta a SQL Server mediante el paquete msodbcsql17. Se ejecuta en el servidor Linux RedHat 7. Al implementar esta aplicación en un nuevo entorno, los administradores locales instalaron el último paquete msodbcsql17 disponible con yum, que es 17.6.1.1-1. Nuestra aplicación se bloquea cuando se conecta a la base de datos, systemctl no puede detenerla, solo la elimina después de un tiempo. Revisé en nuestro laboratorio, la aplicación funciona bien con msodbcsql17 versión 17.4.2.1.1-1. Así que probé versiones tomando uno de nuestros servidores de laboratorio, clonándolo y verificando que la aplicación funciona bien en ambos. Actualicé uno de los servidores a la versión 17.6 de msodbcsql17, la aplicación falló "como se esperaba". Así que lo bajé a la versión 17.4 y la aplicación todavía no funciona.
Por lo que puedo decir, los archivos binarios instalados (todo en la carpeta/opt/microsoft) son los mismos en los dos servidores. Aparte de esto, solo puedo ver un único enlace simbólico de /usr/lib64 que apunta a un archivo SO en /opt/microsoft. Según yum, no se instalaron ni eliminaron otras dependencias. Lo verifiqué exportando la 'lista de yum instalada' a un archivo y comparándolas por diferencias.
Entonces, lo que intenté fue usar rsync para copiar archivos del servidor original en funcionamiento al nuevo servidor. Primero hice ensayos en seco, pero no encontré ninguna diferencia. Así que copié toda la carpeta/usr y todavía no funciona. Luego copié toda la carpeta/etc con rsync, volví a cambiar el nombre de host y la configuración de IP (obviamente estos archivos también se sobrescribieron) y la aplicación comenzó a funcionar nuevamente. Así que lo rompí nuevamente instalando la última versión de msodbcsql17, eliminándolo e instalando la versión anterior, e hice otra ejecución en seco de rsync. En la carpeta usr, no hay diferencias, rsync solo registra que está omitiendo enlaces simbólicos (omitiendo el archivo no normal "tmp"). Sin embargo, en la carpeta etc hubo algunas diferencias y, por mi vida, no puedo ver cuál es el archivo problemático aquí:
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 y /etc/sysconfig/network-scripts/ifcfg-ens160 son obviamente diferentes. /etc/odbcinst.ini se regeneró durante la instalación de msodbcsql17, pero el contenido es el mismo según la diferencia. En cuanto al resto, nuevamente, el contenido es el mismo según diff Bueno, excepto ld.so.cache que es binario, pero el tamaño es diferente, copié este archivo manualmente y no se resolvió.
Así que no estoy seguro de qué es exactamente lo que soluciona el problema aquí. La parte más interesante: si sincronizo la carpeta /etc con el último msodbcsql17 instalado, la aplicación comienza a funcionar nuevamente. Entonces, ¿casi como si algo se rompiera en la carpeta /etc?
Respuesta1
Ok, después de algunas comprobaciones más exhaustivas, parece que me perdí la primera: ¡odbcinst.ini en realidad es diferente! Durante la instalación de msodbc 17.6, se eliminó una línea. Después de agregarlo nuevamente, comenzó a funcionar inmediatamente:
¿Por qué se eliminó esta línea? No lo sé. O, en caso de una instalación nueva, esta línea nunca se agregó a odbcinst.ini. De todos modos, funciona ahora.