bind 升级后的问题

环境是：DC5SP2 X86
BIND：9.2.4到9.4.2
采用的升级步骤如下：

1.登录到应用服务器，切换到root用户。
2. 关闭named服务
命令：#/etc/init.d/named stop
3. 安装BIND升级包
命令：# tar xvfz bind-9.4.2.tar.gz
# cd bind-9.4.2
# ./configure --prefix=/usr/local/named --sysconfdir=/etc/ --localstatedir=/var --enable-threads
# make
# make install
4.生成/etc/rndc.conf
#cd /usr/local/named/sbin
#rndc-confgen>/etc/rndc.conf
5.生成/etc/named.conf文件
# cd /etc
#tail -10 rndc.conf | head -9 | sed s/#\ //g >>named.conf
6.从rndc.conf中提取rndc.key
#cat rndc.conf | head -5 >rndc.key
7.编辑/etc/init.d/named启动,用/usr/local/named/sbin替换/usr/sbin,
将-u named删除
8. 恢复bind配置文件名称 命令：#tar xzvf /root/bind_backup.tar.gz -C /
9. 重新启动即可。
# service named restart
#service named status

    这个过程基本上没有问题，但是在测试环境（以前没有运行过bind）是一切正常的，但是在一个正是环境（一直运行这老版本的bind）却有问题，在最后启动named的时候，报错，日志显示：

Jul 17 16:18:08 hanode1 named[6206]: starting BIND 9.4.2 -t /var/named/chroot
Jul 17 16:18:08 hanode1 named[6206]: found 1 CPU, using 1 worker thread
Jul 17 16:18:08 hanode1 named[6206]: loading configuration from '/etc//named.conf'
Jul 17 16:18:08 hanode1 named[6206]: /etc//named.conf:6: change directory to '/var/named' failed: permission denied
Jul 17 16:18:08 hanode1 named[6206]: /etc//named.conf:6: parsing failed
Jul 17 16:18:08 hanode1 named[6206]: loading configuration: permission denied
Jul 17 16:18:08 hanode1 named[6206]: exiting (due to fatal error)

Jul 17 16:23:37 hanode1 named[6488]: starting BIND 9.4.2 -t /var/named/chroot
Jul 17 08:23:37 hanode1 named[6488]: found 1 CPU, using 1 worker thread
Jul 17 08:23:37 hanode1 named[6488]: loading configuration from '/etc//named.conf'
Jul 17 08:23:37 hanode1 named[6488]: none:0: open: /etc//named.conf: permission denied
Jul 17 08:23:37 hanode1 named[6488]: loading configuration: permission denied
Jul 17 08:23:37 hanode1 named[6488]: exiting (due to fatal error)
Jul 17 16:23:37 hanode1 named: named start failed

    看了看/var/named的权限是没有问题的阿，的确挺奇怪。
    现在需要分析问题，从哪入手呢？有俩个办法，第一个是让/etc/init.d/named打出详细的执行信息，是脚本级调试；第二是用strace跟踪，调试级的，不到万不得已不用，因为很难看懂。
    采用第一种方式，修改/etc/init.d/named第一行，在/bin/bash后面加-x参数，这样就可以打出详细信息：

+ initlog -q -c '/usr/local/named/sbin/named -t /var/named/chroot'
+ '[' 1 -eq 0 ']'
+ failure 'named start'
+ rc=1
+ '[' -z '' ']'
+ initlog -q -n /etc/init.d/named -s 'named start' -e 2
+ '[' color '!=' verbose -a -z '' ']'
+ echo_failure
+ '[' color = color ']'
+ echo -en '\033[60G'

    看来问题就在这个地方，/usr/local/named/sbin/named -t /var/named/chroot这个命令返回了非零值，所以有问题，手工测试了一下，的确返回1。
    在另一个使用系统默认bind的测试环境试了一下这个命令，返回的确是0。那看来就在/var/named/chroot了。
采用比较彻底的方式：

mv /var/named/chroot /var/named/chroot.bak
mkdir /var/named/chroot
cp -rav /var/named/chroot.bak/etc /var/named/chroot
cp -rav /var/named/chroot.bak/dev /var/named/chroot
cp -rav /var/named/chroot.bak/var /var/named/chroot
chown root.named -R /var/named/chroot
/etc/init.d/named start

    先将原来的chroot改名，然后新建，再原来chroot里面的三个目录拷回来，启动正常。

    问题的原因在哪呢？

[root@hanode1 named]# ls chroot.bak/
dev etc proc var
[root@hanode1 named]# ls chroot.bak/proc/
1 2617 2887 3047 41 6658 diskstats iomem locks partitions sysvipc
1471 2621 2930 314 42 acpi dma ioports mdstat pci tty
1849 2673 2947 3164 5 asound driver irq meminfo scsi uptime
188 2688 2956 3216 5713 buddyinfo execdomains kallsyms misc self version
1896 2728 2965 3715 5817 bus fb kcore modules slabinfo vmstat
1900 2729 2966 3889 5885 cmdline filesystems key-users mounts stat
2 2741 3 39 5887 cpuinfo fs keys mpt swaps
21 2742 302 4 6011 crypto ide kmsg mtrr sys
22 2751 3046 40 6511 devices interrupts loadavg net sysrq-trigger
[root@hanode1 named]#

    不知为何，用户环境中/var/named/chroot里面多了一个proc目录，而且这个目录跟/proc是一模一样的，无法删除。可能named启动的时候，需要对此目录做一些操作，但是由于这个proc目录而出现一些问题。至于这个proc是如何产生的，有待推敲。

    在网上找到一个解释：

/var/named/chroot/proc 這個是由 /proc 掛入來使用的。
/proc 是行程相關資訊虛擬目錄，因為 named 有設定 chroot 環境运作，所以使用 mount -t proc proc /var/named/chroot/proc 方式掛入一份提供讓 named 可以於該環境正常运作使用。