Inicialmente perguntei isso no StackOverflow, mas na minha opinião não é um problema de desenvolvimento de aplicativos. Basicamente, tenho um aplicativo C++ que se conecta ao SQL Server usando o pacote msodbcsql17. Ele está rodando no servidor Linux RedHat 7. Ao implantar este aplicativo em um novo ambiente, os administradores locais instalaram o pacote msodbcsql17 mais recente disponível com yum, que é 17.6.1.1-1. Nosso aplicativo trava ao se conectar ao banco de dados, o systemctl não consegue pará-lo, apenas eliminando-o depois de algum tempo. Verifiquei em nosso laboratório, o aplicativo funciona bem com msodbcsql17 versão 17.4.2.1.1-1. Então testei as versões pegando um de nossos servidores de laboratório, clonando-o e verificando se o aplicativo estava funcionando bem em ambos. Atualizei um dos servidores para a versão 17.6 do msodbcsql17, o aplicativo quebrou "conforme esperado". Então fiz downgrade para a versão 17.4 e o aplicativo ainda está quebrado.
Pelo que sei, os binários instalados (tudo na pasta /opt/microsoft) são os mesmos nos dois servidores. Fora isso, só consigo ver um único link simbólico de/usr/lib64 que aponta para um arquivo SO em/opt/microsoft. De acordo com o yum, nenhuma outra dependência foi instalada ou removida, verifiquei isso exportando 'lista yum instalada' para um arquivo e comparando-as por diff.
Então, o que tentei foi usar o rsync para copiar arquivos do servidor original em funcionamento para o novo servidor. Primeiro fiz testes, mas não encontrei nenhuma diferença. Então copiei toda a pasta /usr, ainda não funcionando. Então copiei toda a pasta /etc com rsync, alterei novamente o nome do host e a configuração do IP (obviamente esses arquivos também foram substituídos) e o aplicativo começou a funcionar novamente. Então eu quebrei novamente instalando a versão mais recente do msodbcsql17, removendo-o e instalando a versão anterior, e fiz outra simulação do rsync. Na pasta usr, sem diferenças, o rsync apenas registra que está ignorando links simbólicos (ignorando o arquivo não regular "tmp"). No entanto, na pasta etc havia algumas diferenças e, durante toda a minha vida, não consigo ver qual é o arquivo problemático aqui:
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 e /etc/sysconfig/network-scripts/ifcfg-ens160 são obviamente diferentes. /etc/odbcinst.ini foi regenerado durante a instalação do msodbcsql17, mas o conteúdo é o mesmo de acordo com o diff. Quanto ao resto, novamente, o conteúdo é o mesmo de acordo com o diff. Bom, exceto o ld.so.cache que é binário, mas o tamanho é diferente, copiei esse arquivo manualmente e não resolveu.
Portanto, não tenho certeza do que exatamente está resolvendo o problema aqui. A parte mais interessante: se eu sincronizar novamente a pasta /etc com o msodbcsql17 mais recente instalado, o aplicativo começará a funcionar novamente. Então, quase como se algo quebrasse na pasta /etc?
Responder1
Ok, depois de algumas verificações mais extensas, parece que perdi a primeira: odbcinst.ini é realmente diferente! Durante a instalação do msodbc 17.6, uma linha foi removida. Depois de adicioná-lo novamente, começou a funcionar imediatamente:
Por que essa linha foi removida, eu não sei. Ou, no caso de uma nova instalação, esta linha nunca foi adicionada ao odbcinst.ini. De qualquer forma, funciona agora.