rh7.2以后的DNS是怎么了

rh7.2以后的DNS是怎么了？？？？
用RH7.2配置DNS没有任何问题，用RH8配置DNS，用./named restart发现stop时不出现OK，但解释正常，用RH9时就更离谱，./named restart时居然提示杀不死named进程，解释没有问题，真是晕死，我不知是我有问题，还是RH9有问题，都不知道从何开始修改。请大侠们指点。多谢了！还有用ADSL怎么一直都不能上网呀，莫名其妙，按书上说的都不行，快要去跳楼了，发现RH还是7.2最好用。 
 Re: rh7.2以后的DNS是怎么了？？？？
好像named脚本真的有问题，如果用service named stop或者直接/etc/rc.d/init.d/named stop是停不了进程；一定要用强行杀死方式killall -9 named才把它干得掉！然后用service named start或者/etc/rc.d/init.d/named start重新启动就可以了。奇怪!!!!!!! 
 Re: rh7.2以后的DNS是怎么了？？？？
请把/etc/rc.d/init.d/named中的stop()段落修改为: 
stop() { # Stop daemons. echo -n $"Stopping $prog: " killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named echo return $RETVAL } 
试试效果如何? 解决了! 
不过仍然希望有高手能够解释为什么原脚本中的rndc停不了?以至影响到named停止失效? 
 Re: rh7.2以后的DNS是怎么了？？？？
我restart时出现了一个STOP然后ADSL没有问题啊，我是rh8.0 
 Re: 没问题
service named stop 即可。 
至于不出现stop ok，那只是因为/etc/init.d/named里面没写而已，喜欢的话自己加上。 



 Re: rh7.2以后的DNS是怎么了？？？？
错误。 
你再好好看看原来的启动脚本。 

另外，用up2date保持系统最新。 
 Re: rh7.2以后的DNS是怎么了？？？？
请问你用的是9.0吗？原脚本正如上面的兄弟所讲停不了服务的。 我们用service named stop是没有任何错误提示的，实际上进程还在！你那边有检查过吗？用ps -aux |grep named查看进程还在： 
[root@smsso mail]# ps -aux |grep named named 2223 0.0 0.6 29632 1172 ? S 21:00 0:00 [named] root 4258 0.0 0.3 4812 636 pts/1 S 23:03 0:00 grep named [root@smsso mail]# 
同时系统日志有错误提示如下： [root@smsso mail]# tail -f /var/log/messages Oct 6 23:02:08 smsso named[2223]: app.c:561: unexpected error: Oct 6 23:02:08 smsso named[2223]: isc_app_shutdown() pthread_kill: No such process 
如果是用killall -9 named方式停掉named则不会有任何问题。 我改过脚本后也不会出现这样的问题了。 
改过的脚本在你那边会出错？奇怪！难道真的如你所言我们的9.0的named服务有问题，需要更新？ 
原脚本stop段如下： stop() { # Stop daemons. echo -n $"Stopping $prog: " /usr/sbin/rndc stop RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || { killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named } echo return $RETVAL } 其实我单独去停rndc都会有问题，也是无任何错误提示，但实际上有没停掉。所以我把这一小节去掉直接停named就不会有问题了。（如上文修改） 
是不是没有配置rndc就会这样？我的named工作很正常；98工作端域名解析正常，也说明服务端没问题的了。 但是搞不明白rndc出了什么问题？请高手指教！ 


 Re: rh7.2以后的DNS是怎么了？？？？
我运用中的是8.0。 
9.0我刚装了一下，测试过，没问题。 
>service named stop是没有任何错误提示 
我说了，这只是因为没有调用sucess输出绿色的OK罢了，喜欢自己加上就行了。你好好看看启动脚本。 

>同时系统日志有错误提示如下： >[root@smsso mail]# tail -f /var/log/messages >Oct 6 23:02:08 smsso named[2223]: app.c:561: unexpected error: >Oct 6 23:02:08 smsso named[2223]: isc_app_shutdown() pthread_kill: No such process 
比较遗憾，我的9.0没发现这种情况。这个错误信息我觉得不算正常。 
>改过的脚本在你那边会出错？奇怪！难道真的如你所言我们的9.0的named服务有问题，需要更新？ 
我没说你改动的运行会出错，我是说你改动的本身是错误的。具体嘛，还是要看脚本，我不知道原脚本本身有何错误，你能指出吗？何况你改动以后只是“精简”了原脚本一下，而并没有“修正”什么。而这种精简是没有道理的，所以我说错误。 
详解一下？ 
stop() { # Stop daemons. echo -n $"Stopping $prog: " /usr/sbin/rndc stop RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || { killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named } echo return $RETVAL } 
红色部分我估计你没看懂。这是说，如果rndc stop执行失败，那么执行 
{ killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named } 
也就是强制杀死进程，清除锁，返回。 
如果rndc stop执行成功，那么清除锁，如果清除锁失败(似乎不应该，所以我不知道该不该这么分析，不过仅看脚本是应该这样理解的)，那么也会执行 
{ killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named } 

也就是说，总能完全停止named并清理进程。 

 Re: rh7.2以后的DNS是怎么了？？？？
你对&&与||的联用没有理解透彻，原脚本内容的意思是： stop() { # Stop daemons. echo -n $"Stopping $prog: " /usr/sbin/rndc stop RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named || { killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named } echo return $RETVAL } 
先尝试停止rndc，如果失败，则执行后面段落： {killproc named .............. rm -f /var/lock/subsys/named }； 如果停止rndc成功（既返回值RETVL=0）则尝试清除锁（rm -f /var/lock/subsys/named）； 
尝试清除锁（rm -f /var/lock/subsys/named），如果这里也成功，整个大的判断就结束了； 如果清除失败，则执行后面段落： {killproc named .............. rm -f /var/lock/subsys/named }； 
总结：如果停止rndc成功，并且清除锁也成功，就不做任何事了。这样一来，named进程还活着啊！！ 正如我们观察的一样，用ps查看，named还安静的呆着呢！！！！ 
我更改脚本后的意思你也没看懂，意思是： stop() { # Stop daemons. echo -n $"Stopping $prog: " killproc named RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named echo return $RETVAL } 
不做停止rndc的操作，直接去强行干掉named，如果成功则进一步清除锁。 
现在的问题是：新版本的脚本停止named之前为什么要去处理rndc呢？况且停掉rndc就万事大吉不用再管named了吗？ 
所以请教高手讲解rndc与named的关系！！！！！！ 

 Re: rh7.2以后的DNS是怎么了？？？？
呵呵～～我的理解和解释难道和您的不一样吗？我怎么看不出来不一样呢？麻烦你再看看？ 
rndc都success了，并且锁都清了，竟然还有named进程？或许你是的，俺没遇见过这样的情况。也许你该查查你的rndc。 




 Re: rh7.2以后的DNS是怎么了？？？？
那么请您看看Mandrake9.1下的named脚本,它就干脆没有理会rndc,我还是不清楚直接杀死named和停rndc的区别.请解释,谢谢! 
 Re: rh7.2以后的DNS是怎么了？？？？
没有mandrake。 
直接杀死进程是最简单粗暴的做法，只有在实在必要的时候才作。原因是会丢失log，当然对不需要log（有些服务默认是不要求写log的）或者根本就无所谓的情况来说，跟正常方式没什么区别（有些服务确实直接杀死）。对具体的服务来说可能还有其他磁盘I/O相关的会直接丢弃，甚至可能造成更严重的后果。特别在日志文件系统中。 
我觉得对于server来说，直接kill进程这样的习惯没有最好。或许bind不受影响？那就直接kill吧！ 




 Re: rh7.2以后的DNS是怎么了？？？？
谢谢! 我认真检查了一下我的rndc确实有问题，但是很可惜它不是脚本，无法修改！ 
我无论用rndc stop还是rndc -s localhost stop还是rndc -s smsso.isd.com stop都没任何错误提示（我的主机名是smsso.isd.com） 
但是运行后再执行rdnc status发现bind还在跑呢................ 郁闷！看来rndc这个对bind进行控制的程序真的有问题！ 
rdnc.conf文件也找不出什么不对劲的地方，相信问问题的那位仁兄也碰到了相同的问题吧！ 
 Re: rh7.2以后的DNS是怎么了？？？？
但愿没被攻击，不过看来有迹象。 
最好重装，配置好tripware。 


 真想去跳楼！RedHat公司的人太不负责任了!
说得没有错，不知道我说REDHAT不负责任对还是不对，还有再看看我的ADSL上网更是气死人，好不容易下载到了一个新版的RP-PPPOE，提示连接上了，电信也分配了IP，可就是不能上网，ping DNS提示不通，更为气人的是，以前ping自己的时候都是出现128。。。。 可现在都是64。。。。 速度明显下降了一半，都不知道REDHAT搞什么飞机了，原以为是防火墙的问题，后来关了防火墙停掉IPTABLES还是不行，真是快要去跳楼。 用mandrake很容易就实现ADSL上网了。 ./named提示也很成功，rndc也没有出错。 lhl牛哥哥，楼上的兄弟说得没有错，service named stop后还是有named进程，说到攻击，应不可能，我是新装的从来没有上过网，怎么会呢？？ mandrake虽然占资源，可有些地方和REDHAT比起来就是要好，虽然我的潜意识是喜欢REDHAT的。 
 Re: 真想去跳楼！RedHat公司的人太不负责任了!
如果没有得到希望的结果，最应该的是检查自己做错了什么，而不是平白怀疑RedHat是否负责任。我认为这样重要的服务如果确实在启动脚本就有问题，那也早在第一个测试版就得到修正了，网上那么多有能力的开发者和管理员不会连这样的问题都发现不了的。具体到bind这个脚本，我也希望谁能指明到底在哪里存在什么样的错误，我相信redhat同样感谢发现问题的人，问题是，有错误吗？ 

ping的128和64等等不表示速度，跟router有关。如果你在linux上ping，time才是延迟。 
[hleil@rh90 hleil]$ ping 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.079 ms 
抄一段TTL的解释， 
The Time To Live (TTL) field can be interesting. Every IP packet that gets sent out has a TTL field which is set to a relatively high number (in this case, ping packets get a TTL of 255). As the packet traverses the network, the TTL field gets decreased by one by each router it goes through; when the TTL drops to 0, the packet is discarded by the router. The IP spec says that the TTL should be set to 60 (though it's 255 for ping packets). The main purpose of this is so that a packet doesn't live forever on the network and will eventually die when it is deemed "lost." But for us, it provides additional information. We can use the TTL to determine approximately how many router hops the packet has gone through. In this case it's 255 minus N hops, where N is the TTL of the returning Echo Replies. If the TTL field varies in successive pings, it could indicate that the successive reply packets are going via different routes, which isn't a great thing. 

至于ADSL的问题，我想是你自己的问题。搞清楚路由和网络设置你就差不多不会再报怨RedHat搞不定ADSL了。 



 Re: 真想去跳楼！RedHat公司的人太不负责任了!
诚然，怀疑REDHAT的想法是不对的，可我觉得还是不能释怀，同样的REDHAT，我用同样的做法，在7.2上就可以，在9.0上敲破了头都不行。所以感到很郁闷。可能自己没有系统的看文档，这些天得细细看看才行。 BTW：adsl有了电信IP，我想也应是路由在作怪，只是一下子不知道问题出在哪里。 

 关于redhat上的named stop问题
liro提的这个问题的确很普遍，不过它也很特殊。特殊就在于它恰好存在于redhat 9+bind 9这样的平台上。在Redhat网站上有这个问题的解决方法，参见：http://www.redhat.com/archives/redhat-list/2003-April/msg00760.html。 
不过这也就是解决方法而已，却没有具体的原因说明。但是至少可以明确bind9的“水土不服”实际是与kernel-2.4.20-20.8内核程序环境有关，而非redhat发布版本本身的设置。看来bind 9在rndc这个工具上还需下点功夫。 
谈到rndc，还想多说几句。如果你是希望使新的配置生效，最好使用rndc reload，而尽量避免重新启动服务程序。此外，直接kill掉named服务的方式也不大可取。 


 Re: 关于redhat上的named stop问题
看过了，出问题的内核似乎应该是2.4.20-8，因为文章时间是Apr 24 20:55:01 2003。也就是RedHat9最初携带的内核。 
所以说up2date还是有用的，因为最新内核是2.4.20-20.9。我看不到这个现象的原因估计也是因为内核已经更新。 


 Re: 真想去跳楼！RedHat公司的人太不负责任了!
重新下载了ADSL拔号程序，再折腾了大半天，终于可以上网了。但不知何解，一定要先执行这个步骤 ifconfig eth0 0.0.0.0 up 才行，而Mandrake又不需要这个步骤。感到不可以理解的是，为什么要执行这个步骤？并且连上internet后，我发现网卡的连接变成了inactive,inactive的意思是没有连接，失效了，那网卡和ADSL怎么实现通信？请LHL老大指点指点。 
 Re: 真想去跳楼！RedHat公司的人太不负责任了!
关键点就是拨号后，默认网关必须指向ADSL或者modem。只要这点OK，其它的都OK。网卡部分不需要改动。 

 Re: 关于redhat上的named stop问题
怎樣updte 
 Re: 关于redhat上的named stop问题
as root,run up2date