免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

打開APP
userphoto
未登錄

開通VIP,暢享免費(fèi)電子書等14項超值服

開通VIP
rh7.2以后的DNS是怎么了
rh7.2以后的DNS是怎么了????

用RH7.2配置DNS沒有任何問題,用RH8配置DNS,用./named restart發(fā)現(xiàn)stop時不出現(xiàn)OK,但解釋正常,用RH9時就更離譜,./named restart時居然提示殺不死named進(jìn)程,解釋沒有問題,真是暈死,我不知是我有問題,還是RH9有問題,都不知道從何開始修改。請大俠們指點(diǎn)。多謝了!還有用ADSL怎么一直都不能上網(wǎng)呀,莫名其妙,按書上說的都不行,快要去跳樓了,發(fā)現(xiàn)RH還是7.2最好用。 

 Re: rh7.2以后的DNS是怎么了????

好像named腳本真的有問題,如果用service named stop或者直接/etc/rc.d/init.d/named stop是停不了進(jìn)程;一定要用強(qiáng)行殺死方式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時出現(xiàn)了一個STOP然后ADSL沒有問題啊,我是rh8.0 

 Re: 沒問題

service named stop 
即可。 

至于不出現(xiàn)stop ok,那只是因為/etc/init.d/named里面沒寫而已,喜歡的話自己加上。 




 Re: rh7.2以后的DNS是怎么了????

錯誤。 

你再好好看看原來的啟動腳本。 


另外,用up2date保持系統(tǒng)最新。 

 Re: rh7.2以后的DNS是怎么了????

請問你用的是9.0嗎?原腳本正如上面的兄弟所講停不了服務(wù)的。 
我們用service named stop是沒有任何錯誤提示的,實際上進(jìn)程還在!你那邊有檢查過嗎?用ps -aux |grep named查看進(jìn)程還在: 

[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]# 

同時系統(tǒng)日志有錯誤提示如下: 
[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則不會有任何問題。 
我改過腳本后也不會出現(xiàn)這樣的問題了。 

改過的腳本在你那邊會出錯?奇怪!難道真的如你所言我們的9.0的named服務(wù)有問題,需要更新? 

原腳本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 
其實我單獨(dú)去停rndc都會有問題,也是無任何錯誤提示,但實際上有沒停掉。所以我把這一小節(jié)去掉直接停named就不會有問題了。(如上文修改) 

是不是沒有配置rndc就會這樣?我的named工作很正常;98工作端域名解析正常,也說明服務(wù)端沒問題的了。 
但是搞不明白rndc出了什么問題?請高手指教! 



 Re: rh7.2以后的DNS是怎么了????

我運(yùn)用中的是8.0。 

9.0我剛裝了一下,測試過,沒問題。 

>service named stop是沒有任何錯誤提示 

我說了,這只是因為沒有調(diào)用sucess輸出綠色的OK罷了,喜歡自己加上就行了。你好好看看啟動腳本。 


>同時系統(tǒng)日志有錯誤提示如下: 
>[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沒發(fā)現(xiàn)這種情況。這個錯誤信息我覺得不算正常。 

>改過的腳本在你那邊會出錯?奇怪!難道真的如你所言我們的9.0的named服務(wù)有問題,需要更新? 

我沒說你改動的運(yùn)行會出錯,我是說你改動的本身是錯誤的。具體嘛,還是要看腳本,我不知道原腳本本身有何錯誤,你能指出嗎?何況你改動以后只是“精簡”了原腳本一下,而并沒有“修正”什么。而這種精簡是沒有道理的,所以我說錯誤。 

詳解一下? 

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執(zhí)行失敗,那么執(zhí)行 

killproc named 
RETVAL=$? 
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named 

也就是強(qiáng)制殺死進(jìn)程,清除鎖,返回。 

如果rndc stop執(zhí)行成功,那么清除鎖,如果清除鎖失敗(似乎不應(yīng)該,所以我不知道該不該這么分析,不過僅看腳本是應(yīng)該這樣理解的),那么也會執(zhí)行 

killproc named 
RETVAL=$? 
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named 


也就是說,總能完全停止named并清理進(jìn)程。 


 Re: rh7.2以后的DNS是怎么了????

你對&&與||的聯(lián)用沒有理解透徹,原腳本內(nèi)容的意思是: 
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,如果失敗,則執(zhí)行后面段落: 
{killproc named .............. rm -f /var/lock/subsys/named }; 
如果停止rndc成功(既返回值RETVL=0)則嘗試清除鎖(rm -f /var/lock/subsys/named); 

嘗試清除鎖(rm -f /var/lock/subsys/named),如果這里也成功,整個大的判斷就結(jié)束了; 
如果清除失敗,則執(zhí)行后面段落: 
{killproc named .............. rm -f /var/lock/subsys/named }; 

總結(jié):如果停止rndc成功,并且清除鎖也成功,就不做任何事了。這樣一來,named進(jìn)程還活著啊?。?nbsp;
正如我們觀察的一樣,用ps查看,named還安靜的呆著呢!?。。?nbsp;

我更改腳本后的意思你也沒看懂,意思是: 
stop() { 
# Stop daemons. 
echo -n $"Stopping $prog: " 
killproc named 
RETVAL=$? 
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/named 
echo 
return $RETVAL 

不做停止rndc的操作,直接去強(qiáng)行干掉named,如果成功則進(jìn)一步清除鎖。 

現(xiàn)在的問題是:新版本的腳本停止named之前為什么要去處理rndc呢?況且停掉rndc就萬事大吉不用再管named了嗎? 

所以請教高手講解rndc與named的關(guān)系?。。。。?! 


 Re: rh7.2以后的DNS是怎么了????

呵呵~~我的理解和解釋難道和您的不一樣嗎?我怎么看不出來不一樣呢?麻煩你再看看? 

rndc都success了,并且鎖都清了,竟然還有named進(jìn)程?或許你是的,俺沒遇見過這樣的情況。也許你該查查你的rndc。 





 Re: rh7.2以后的DNS是怎么了????

那么請您看看Mandrake9.1下的named腳本,它就干脆沒有理會rndc,我還是不清楚直接殺死named和停rndc的區(qū)別.請解釋,謝謝! 

 Re: rh7.2以后的DNS是怎么了????

沒有mandrake。 

直接殺死進(jìn)程是最簡單粗暴的做法,只有在實在必要的時候才作。原因是會丟失log,當(dāng)然對不需要log(有些服務(wù)默認(rèn)是不要求寫log的)或者根本就無所謂的情況來說,跟正常方式?jīng)]什么區(qū)別(有些服務(wù)確實直接殺死)。對具體的服務(wù)來說可能還有其他磁盤I/O相關(guān)的會直接丟棄,甚至可能造成更嚴(yán)重的后果。特別在日志文件系統(tǒng)中。 

我覺得對于server來說,直接kill進(jìn)程這樣的習(xí)慣沒有最好?;蛟Sbind不受影響?那就直接kill吧! 





 Re: rh7.2以后的DNS是怎么了????

謝謝! 
我認(rèn)真檢查了一下我的rndc確實有問題,但是很可惜它不是腳本,無法修改! 

我無論用rndc stop還是rndc -s localhost stop還是rndc -s smsso.isd.com stop都沒任何錯誤提示(我的主機(jī)名是smsso.isd.com) 

但是運(yùn)行后再執(zhí)行rdnc status發(fā)現(xiàn)bind還在跑呢................ 
郁悶!看來rndc這個對bind進(jìn)行控制的程序真的有問題! 

rdnc.conf文件也找不出什么不對勁的地方,相信問問題的那位仁兄也碰到了相同的問題吧! 

 Re: rh7.2以后的DNS是怎么了????

但愿沒被攻擊,不過看來有跡象。 

最好重裝,配置好tripware。 



 真想去跳樓!RedHat公司的人太不負(fù)責(zé)任了!

說得沒有錯,不知道我說REDHAT不負(fù)責(zé)任對還是不對,還有再看看我的ADSL上網(wǎng)更是氣死人,好不容易下載到了一個新版的RP-PPPOE,提示連接上了,電信也分配了IP,可就是不能上網(wǎng),ping DNS提示不通,更為氣人的是,以前ping自己的時候都是出現(xiàn)128。。。。 
可現(xiàn)在都是64。。。。 
速度明顯下降了一半,都不知道REDHAT搞什么飛機(jī)了,原以為是防火墻的問題,后來關(guān)了防火墻停掉IPTABLES還是不行,真是快要去跳樓。 
用mandrake很容易就實現(xiàn)ADSL上網(wǎng)了。 
./named提示也很成功,rndc也沒有出錯。 
lhl牛哥哥,樓上的兄弟說得沒有錯,service named stop后還是有named進(jìn)程,說到攻擊,應(yīng)不可能,我是新裝的從來沒有上過網(wǎng),怎么會呢?? 
mandrake雖然占資源,可有些地方和REDHAT比起來就是要好,雖然我的潛意識是喜歡REDHAT的。 

 Re: 真想去跳樓!RedHat公司的人太不負(fù)責(zé)任了!

如果沒有得到希望的結(jié)果,最應(yīng)該的是檢查自己做錯了什么,而不是平白懷疑RedHat是否負(fù)責(zé)任。我認(rèn)為這樣重要的服務(wù)如果確實在啟動腳本就有問題,那也早在第一個測試版就得到修正了,網(wǎng)上那么多有能力的開發(fā)者和管理員不會連這樣的問題都發(fā)現(xiàn)不了的。具體到bind這個腳本,我也希望誰能指明到底在哪里存在什么樣的錯誤,我相信redhat同樣感謝發(fā)現(xiàn)問題的人,問題是,有錯誤嗎? 


ping的128和64等等不表示速度,跟router有關(guān)。如果你在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的問題,我想是你自己的問題。搞清楚路由和網(wǎng)絡(luò)設(shè)置你就差不多不會再報怨RedHat搞不定ADSL了。 




 Re: 真想去跳樓!RedHat公司的人太不負(fù)責(zé)任了!

誠然,懷疑REDHAT的想法是不對的,可我覺得還是不能釋懷,同樣的REDHAT,我用同樣的做法,在7.2上就可以,在9.0上敲破了頭都不行。所以感到很郁悶??赡茏约簺]有系統(tǒng)的看文檔,這些天得細(xì)細(xì)看看才行。 
BTW:adsl有了電信IP,我想也應(yīng)是路由在作怪,只是一下子不知道問題出在哪里。 


 關(guān)于redhat上的named stop問題

liro提的這個問題的確很普遍,不過它也很特殊。特殊就在于它恰好存在于redhat 9+bind 9這樣的平臺上。在Redhat網(wǎng)站上有這個問題的解決方法,參見:http://www.redhat.com/archives/redhat-list/2003-April/msg00760.html。 

不過這也就是解決方法而已,卻沒有具體的原因說明。但是至少可以明確bind9的“水土不服”實際是與kernel-2.4.20-20.8內(nèi)核程序環(huán)境有關(guān),而非redhat發(fā)布版本本身的設(shè)置。看來bind 9在rndc這個工具上還需下點(diǎn)功夫。 

談到rndc,還想多說幾句。如果你是希望使新的配置生效,最好使用rndc reload,而盡量避免重新啟動服務(wù)程序。此外,直接kill掉named服務(wù)的方式也不大可取。 



 Re: 關(guān)于redhat上的named stop問題

看過了,出問題的內(nèi)核似乎應(yīng)該是2.4.20-8,因為文章時間是Apr 24 20:55:01 2003。也就是RedHat9最初攜帶的內(nèi)核。 

所以說up2date還是有用的,因為最新內(nèi)核是2.4.20-20.9。我看不到這個現(xiàn)象的原因估計也是因為內(nèi)核已經(jīng)更新。 



 Re: 真想去跳樓!RedHat公司的人太不負(fù)責(zé)任了!

重新下載了ADSL拔號程序,再折騰了大半天,終于可以上網(wǎng)了。但不知何解,一定要先執(zhí)行這個步驟 
ifconfig eth0 0.0.0.0 up 
才行,而Mandrake又不需要這個步驟。感到不可以理解的是,為什么要執(zhí)行這個步驟?并且連上internet后,我發(fā)現(xiàn)網(wǎng)卡的連接變成了inactive,inactive的意思是沒有連接,失效了,那網(wǎng)卡和ADSL怎么實現(xiàn)通信?請LHL老大指點(diǎn)指點(diǎn)。 

 Re: 真想去跳樓!RedHat公司的人太不負(fù)責(zé)任了!

關(guān)鍵點(diǎn)就是撥號后,默認(rèn)網(wǎng)關(guān)必須指向ADSL或者modem。只要這點(diǎn)OK,其它的都OK。網(wǎng)卡部分不需要改動。 


 Re: 關(guān)于redhat上的named stop問題

怎樣updte 

 Re: 關(guān)于redhat上的named stop問題

as root,run up2date
本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點(diǎn)擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
rndc:connectfailed解決
ubuntu 搭建局域網(wǎng)內(nèi)DNS服務(wù)器 | 學(xué)步園
智能DNS那些事(基于bind9 view的主從配置)
[原創(chuàng)] 架設(shè)dns全攻略
01--DNS服務(wù)器3
DNS 深度理解 [ 一 ]
更多類似文章 >>
生活服務(wù)
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點(diǎn)擊這里聯(lián)系客服!

聯(lián)系客服