ISC BIND拒绝启动：“退出（由于致命错误）”

在IBM X服务器的CentOS 6.4 x64上绑定9.8.2。

将官方的Centos更新仓库中的9.8.2捆绑到工作正常，但是我需要通过源码编译来进行调整（这里没有什么疯狂的东西 – 只是用CentOS RPM提供的不同的选项编译）注意，我使用源码绑定-9.9.4，而不是9.8.x，所以也许这是潜在的问题？我怀疑它，但它是可能的）。
最近，我决定回到从RPM安装，但现在，我不能绑定启动。

我得到的唯一信息是什么都不告诉我：

# 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)

named.conf中的语法错误和文件权限错误通常在loading configuration: failure之前列出loading configuration: failure log line，但在这种情况下，没有错误，所以我不知道发生了什么。

有趣的是，如果我从我的源编译（make install）重新安装绑定，绑定工作得很好。现在我只使用标准的默认named.conf。我不打扰在这里发布，因为我知道这是有效的 – 这不是问题在这里。我觉得我可能已经不小心删除了一个共享库或什么东西，在我的摆弄…粘手指？工作累了吗？谁知道。

这是我用编译绑定的选项，如果有帮助：

 ./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

好吧，我会切入正题。我不需要通过这个过程，但我需要一个方向，我不知道如何进一步debugging这个问题。例如，我将如何监视某个进程（例如named）是否正在查询共享库或不在那里的资源？除了“-g”之外，绑定没有额外冗长的标志。 “-d”标志不给这个错误更多的冗长。如何进一步解决这个问题？ Ktrace或其他一些debugging工具？我很茫然，会喜欢一些build议。

我试过的东西：

yum reinstall在repoquery --requires --recursive --resolve bind列出的每个软件包上yum reinstall repoquery --requires --recursive --resolve bind ， repoquery --requires --recursive --resolve bind-utils ， repoquery --requires --recursive --resolve bind-libs
yum remove bind bind-utils bind-libs ，然后手动删除所有剩余的消息，然后重新安装这三个包
重新安装从RPM绑定后运行ldconfig （完全多余的，但是什么）
SElinux已禁用，App Armor未安装

我真的希望ISC开发者已经做出了一个uninstall目标，因为从源代码编译后，真的没有简单的方法（我知道）来卸载绑定。（请随时给我启发）。

感谢任何指针，如果你需要更多的信息，让我知道。

***编辑

从su - named -c "/usr/sbin/named -d 9 -g -c /etc/named.conf" -s /bin/bash输出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)

最后，多一点线索！我一直使用“-d 10”绑定，这显然不存在，所以难怪它没有给我任何额外的debugging信息。上面的消息是没有什么具体的谷歌，但我会继续寻找。如果这个stream光溢彩，请让我知道。

尝试“名为-d 9”，是的，它不寻常的不告诉你为什么…

解决了！原来是/ usr / lib中的一堆32位共享库。当我从源代码编译/安装时，它们必须已经到达那里，并且它们优先于/ usr / lib64。事实上，现在我想到了，我敢打赌，我是为i386编译的，或者是我把64位安装目标指向了/ usr / lib。

当我删除它们，然后从centos回购重新安装绑定，一切终于按预期工作。

这里是/ usr / lib中的文件，如果有人感兴趣的话：

 -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