ISC BIND se recusa a iniciar: “sair (devido a erro fatal)”

1

Vincule 9.8.2 ao CentOS 6.4 x64 no servidor IBM X.

A ligação 9.8.2 do repositório oficial de atualizações do Centos costumava funcionar bem, mas depois eu precisei ajustá-lo compilando a partir do código-fonte (nada maluco aqui - apenas compilado com opções diferentes das oferecidas no CentOS RPM. a fonte do bind-9.9.4, não 9.8.x, então talvez isso seja potencialmente o problema? Eu duvido, mas é possível). Recentemente, decidi voltar a instalar a partir do RPM, mas agora não consigo que o Bind seja iniciado.

As únicas mensagens que recebo não me dizem nada:

# named -g -c /etc/named.conf
01-Dec-2013 15:46:57.899 starting BIND 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6 -g -c /etc/named.conf
01-Dec-2013 15:46:57.899 built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE'
01-Dec-2013 15:46:57.899 ----------------------------------------------------
01-Dec-2013 15:46:57.899 BIND 9 is maintained by Internet Systems Consortium,
01-Dec-2013 15:46:57.899 Inc. (ISC), a non-profit 501(c)(3) public-benefit
01-Dec-2013 15:46:57.899 corporation.  Support and training for BIND 9 are
01-Dec-2013 15:46:57.899 available at https://www.isc.org/support
01-Dec-2013 15:46:57.899 ----------------------------------------------------
01-Dec-2013 15:46:57.899 adjusted limit on open files from 4096 to 1048576
01-Dec-2013 15:46:57.899 found 24 CPUs, using 24 worker threads
01-Dec-2013 15:46:57.900 using up to 4096 sockets
01-Dec-2013 15:46:57.907 loading configuration: failure
01-Dec-2013 15:46:57.907 exiting (due to fatal error)

Erros de sintaxe no named.conf e erros de permissão de arquivo são normalmente listados logo antes da linha loading configuration: failure log, mas, neste caso, não há erro, então não sei o que está acontecendo.

O engraçado é que, se eu reinstalar o bind da minha compilação de origem (make install), o bind funciona muito bem. No momento, estou apenas usando o padrão padrão named.conf. Não vou me incomodar em postar aqui porque sei que é válido - essa não é a questão aqui. Eu sinto que eu posso ter acidentalmente deletado uma libra compartilhada ou algo assim, durante meus dedos ... pegajosos? trabalhando quando cansado? quem sabe.

Aqui estão as opções que usei para compilar o bind, se isso ajudar:

./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-libtool --localstatedir=/var --enable-threads --with-dlz-filesystem=yes --with-gssapi=/usr/include/gssapi --enable-fixed-rrset --with-dlopen=yes

Ok, então vou direto ao assunto. Não preciso da minha mão durante esse processo, mas preciso de uma direção para entrar. Não tenho ideia de como depurar ainda mais esse problema. Por exemplo, como eu monitoraria se um processo (por exemplo, chamado) está ou não consultando uma biblioteca compartilhada ou um recurso que não está lá? Bind não tem uma bandeira para verbosidade extra, além do que "-g" faz. O sinalizador "-d" não fornece mais verbosidade para esse erro. Como alguém poderia resolver isso ainda mais? Ktrace, ou alguma outra ferramenta de depuração? Estou perplexo e adoraria algumas sugestões.

Coisas que eu tentei:

  • yum reinstall em todos os pacotes listados em repoquery --requires --recursive --resolve bind , repoquery --requires --recursive --resolve bind-utils , repoquery --requires --recursive --resolve bind-libs
  • yum remove bind bind-utils bind-libs , em seguida, remova manualmente todas as informações restantes e, em seguida, reinstale esses três pacotes
  • Executando ldconfig após reinstalar o bind do RPM (totalmente redundante, mas o que diabos)
  • O SElinux está desativado e o App Armor não está instalado

Eu realmente queria que os desenvolvedores do ISC tivessem feito um uninstall make target, porque não há realmente nenhuma maneira fácil (que eu saiba) de desinstalar o bind após compilar a partir do código fonte. (Sinta-se à vontade para me esclarecer lá).

Obrigado por qualquer indicação, e se precisar de mais informações, me avise.

*** EDITAR

Saída de su - named -c "/usr/sbin/named -d 9 -g -c /etc/named.conf" -s /bin/bash :

01-Dec-2013 17:16:30.994 Registering DLZ_dlopen driver
01-Dec-2013 17:16:30.994 Registering SDLZ driver 'dlopen'
01-Dec-2013 17:16:30.994 Registering DLZ driver 'dlopen'
01-Dec-2013 17:16:30.996 decrement_reference: delete from rbt: 0x7ff208214068 .
01-Dec-2013 17:16:31.001 load_configuration: failure
01-Dec-2013 17:16:31.001 loading configuration: failure
01-Dec-2013 17:16:31.001 exiting (due to fatal error)

Finalmente, um pouco mais de uma pista! Eu estava usando "-d 10" com bind, que aparentemente não existe, então não é de admirar que não tenha me dado nenhuma informação adicional de depuração. A mensagem acima não está criando nada de concreto no Google, mas continuarei pesquisando. Se isso derramar alguma luz, por favor me avise.

    
por sbgoodwin 02.12.2013 / 02:00

2 respostas

0

tente 'named -d 9' e sim, é incomum não dizer por que ...

    
por 02.12.2013 / 02:11
0

Resolvido! Acontece que era um monte de libs compartilhadas de 32 bits em / usr / lib. Eles devem ter chegado lá quando eu compilei / instalei a partir do código-fonte, e eles tomaram precedência (?) Sobre os que estão em / usr / lib64. Na verdade, agora que penso nisso, aposto que compilei para o i386 ou direcionei o destino de instalação de 64 bits para / usr / lib.

Depois que eu os deletei, então reinstalei o bind do repositório centos, tudo finalmente funciona como esperado.

Aqui estão os arquivos que estavam em / usr / lib, se alguém estiver interessado:

-rw-r--r--. 1 root root 10220682 Oct  8 00:42 libdns.a
-rw-r--r--. 1 root root     1010 Oct  8 00:42 libdns.la
lrwxrwxrwx. 1 root root       17 Oct 10 00:02 libdns.so.100 -> libdns.so.100.1.1
-rw-r--r--  1 root root  6026006 Oct  8 00:42 libdns.so.100.1.1
lrwxrwxrwx. 1 root root       17 Oct 10 00:02 libdns.so.122 -> libdns.so.122.1.0
-rw-r--r--. 1 root root  5761978 Oct  8 00:18 libdns.so.122.1.0
-rw-r--r--. 1 root root  2083570 Oct  8 00:42 libisc.a
-rw-r--r--. 1 root root   170672 Oct  8 00:42 libisccc.a
-rw-r--r--. 1 root root      971 Oct  8 00:42 libisccc.la
lrwxrwxrwx. 1 root root       18 Oct 10 00:02 libisccc.so.80 -> libisccc.so.80.0.4
-rw-r--r--. 1 root root   102388 Oct  8 00:18 libisccc.so.80.0.4
lrwxrwxrwx. 1 root root       18 Oct 10 00:02 libisccc.so.90 -> libisccc.so.90.0.4
-rw-r--r--. 1 root root   105996 Oct  8 00:42 libisccc.so.90.0.4
-rw-r--r--. 1 root root   432498 Oct  8 00:42 libisccfg.a
-rw-r--r--. 1 root root     1067 Oct  8 00:42 libisccfg.la
lrwxrwxrwx. 1 root root       19 Oct 10 00:02 libisccfg.so.82 -> libisccfg.so.82.0.7
-rw-r--r--. 1 root root   289960 Oct  8 00:18 libisccfg.so.82.0.7
lrwxrwxrwx. 1 root root       19 Oct 10 00:02 libisccfg.so.90 -> libisccfg.so.90.0.7
-rw-r--r--  1 root root   298219 Oct  8 00:42 libisccfg.so.90.0.7
-rw-r--r--. 1 root root      938 Oct  8 00:42 libisc.la
lrwxrwxrwx. 1 root root       16 Oct 10 00:02 libisc.so.84 -> libisc.so.84.5.1
-rw-r--r--. 1 root root  1150027 Oct  8 00:18 libisc.so.84.5.1
lrwxrwxrwx. 1 root root       16 Oct 10 00:02 libisc.so.95 -> libisc.so.95.2.1
-rw-r--r--. 1 root root  1178391 Oct  8 00:42 libisc.so.95.2.1
-rw-r--r--. 1 root root   431628 Oct  8 00:42 liblwres.a
-rw-r--r--. 1 root root      952 Oct  8 00:42 liblwres.la
lrwxrwxrwx. 1 root root       18 Oct 10 00:02 liblwres.so.80 -> liblwres.so.80.0.7
-rw-r--r--. 1 root root   239863 Oct  8 00:18 liblwres.so.80.0.7
lrwxrwxrwx. 1 root root       18 Oct 10 00:02 liblwres.so.90 -> liblwres.so.90.0.5
-rw-r--r--. 1 root root   243111 Oct  8 00:42 liblwres.so.90.0.5
    
por 02.12.2013 / 05:38