fundo
Vim aqui esta manhã, recebi uma saudação de um aluno front-end no WeChat e postei um bug para mim. Por que não consigo fazer login no ambiente mit?
Em um instante, lembrei que as 3 máquinas no ambiente mit foram todas paradas para depurar uma função, o que também fez com que o websocket acima falhasse ao fazer login (PS: android e ios estão logados obtendo endereços IP dinâmicos através de o serviço de balanceamento de carga desenvolvido por eles mesmos. Portanto, não será afetado. Mas a web usa nginx + nome de domínio e as 3 máquinas mapeadas pelo nome de domínio são interrompidas e definitivamente não poderão fazer login.)
Apresse-se e retire a ferramenta jenkins que você construiu e implante N máquinas com um clique. Não é muito legal: o
CICD usa o Jenkins em combate para obter implantação automatizada e isolamento de ambiente
PS: O princípio de funcionamento do jenkins é mais ou menos como mostrado na figura acima. Cada vez que você compila, você primeiro extrai um código do github / gitlab e, após a compilação (escreve seu próprio script), pode distribuí-lo para várias máquinas que precisam a ser implantado para implantação (escreva seu próprio script para controlar).
1. Clique em Build
2. Visualize o resultado do console.
Descobri que tudo está normal, mas o processo simplesmente não inicia. Qual é o problema?
[root@10-0-59-178 webapps]# ls
online.base.immsgserver.service online.base.immsgserver.service.202006026
Então, eu o executei manualmente:
Por que não consigo encontrar libdb-4.7.so?
[root@10-0-59-178 msg_server]# whereis libdb-4.7.so
libdb-4.7:[root@10-0-59-178 msg_server]#
[root@10-0-59-178 msg_server]# whereis libdb-5.3.so
libdb-5.3: /usr/lib64/libdb-5.3.so
a razão
Para descobrir o motivo, usei o ldd para dar uma olhada nas dependências:
Máquinas que não podem ser executadas: Máquinas que
funcionam bem:
por que isso?
No final, depois de passar mais de uma hora , descobri que o log4cxx.so compilado anteriormente foi usado diretamente no script build.sh em vez de recompilar log4cxx todas as vezes.
copy_libs(){
# lib
# 解决jekins发布job编译过长问题，故提前编译好protobuf、log4cxx、hiredis等，节约时间
cp ${CUR_DIR}/lib/linux/* ${CUR_DIR}/lib/
}
Portanto, apenas recompile o log4cxx. ldd veja o compilado:
[root@10-0-59-231 linux]# ldd liblog4cxx.so
linux-vdso.so.1 => (0x00007ffd36155000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f8597d0b000)
libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f8597aab000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f859789c000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f8597672000)
libdb-5.3.so => /usr/lib64/libdb-5.3.so (0x00007f85972b2000)
Resumindo
Então, por que os programadores do Linux gostam de compilar o código-fonte de uma biblioteca dependente ? Acho que um dos motivos é evitar o problema de não encontrar bibliotecas dependentes devido a ambientes inconsistentes .
Apêndice
1. Comando ldd para visualizar dependências
ldd msg_server
linux-vdso.so.1 => (0x00007fff3d4fc000)
libslog.so => ./libslog.so (0x00007fad6a9be000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fad6a555000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fad6a339000)
libssl.so.10 => /lib64/libssl.so.10 (0x00007fad6a0c7000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fad69dbd000)
libm.so.6 => /lib64/libm.so.6 (0x00007fad69abb000)
2.ldd exibe apenas não encontrado:
ldd msg_server |grep "not found"
Resultado
libdb-4.7.so => not found
3. Desmontagem Objdump para ver as bibliotecas dependentes ausentes
objdump -x liblog4cxx.so|grep NEEDED
Resultado
[root@10-0-59-178 msg_server]# objdump -x liblog4cxx.so|grep NEEDED
NEEDED libaprutil-1.so.0
NEEDED libldap-2.4.so.2
NEEDED liblber-2.4.so.2
NEEDED libexpat.so.1
NEEDED libdb-4.7.so
NEEDED libapr-1.so.0
NEEDED libpthread.so.0
NEEDED libstdc++.so.6
NEEDED libm.so.6
NEEDED libc.so.6
NEEDED libgcc_s.so.1