ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次古怪的排障

一次古怪的排障

原创 Linux操作系统 作者:萧筱筱 时间:2010-10-17 09:59:47 0 删除 编辑

有天同事问了我一个很奇怪的问题,ftp server是不是有什么配置导致30秒的延时...

我很疑惑,在我看来,ftp server不需要做这样的设置... 在他座位边仔细观察出现超时的现象,登录过程很正常,但是get 文件的时候,却要等待30秒

上现场的服务器检查,redhat 5.3的操作系统,vsftp的server,所有配置看起来都很正常。去掉chroot进行ftp下载测试,本地目录下的文件获取也十分正常,但是在挂载到服务器上的一个nfs的文件系统上下载却要30秒的延时...?

在服务器上从nfs挂载的文件系统上cp文件也十分正常... 奇哉怪哉!!

初步结论:ftp server本身无问题,问题可能出在以下几个方面:

1. nfs server,2. 服务器与nfs server的连接或者访问上

登录到另外一台也挂载了同样nfs文件系统服务器上,做同样的ftp下载操作,一切正常。

排除因素1

找网络维护的同事检查端口,只是发现端口流量特别大,其他没有特别的异常...

自此陷入怪圈... 不明所以,近来十分惫懒的我,已经开始懈怠了...

同事很执着,还在研究,过了1个多小时,告诉我message中发现有这样的报错:

Oct  9 17:13:42 node kernel: lockd: failed to monitor xx.xx.xx.xx
Oct  9 17:14:11 node  kernel: statd: server localhost not responding, timed out

并且,两条日志之间的时间间隔正好是30秒... 越发的诡异... 直觉上认为ftp获取文件时延时30秒与这30秒有一定的关联关系

google这个报错,却茫然毫无头绪,诸如redhat bug之类的信息比比皆是,不会这么背吧?看到有一个帖子里建议检查一下statd的状态,果然,检查之后发现statd并未启动...

继续google statd无法启动的原因,更加莫名,statd和lockd通常是在nfs client 上起的,lockd用来在写文件时加锁保护,statd用来确认nfs共享的文件系统的状态。并且,而且,以及... statd通常是起lockd时同时启动的,无需单独启动。

那... 那谁不让statd启动呢?莫名...

无奈之下,只好直接看lockd的开机自启动脚本,/etc/init.d/nfslock,检查半天,发现statd可以手工启动,并且statd启动之后,ftp获取文件就正常了...

咳咳,那...那为什么这么标准化的开机自启动脚本,起不来statd了呢???  反反复复看了几遍那个不到100行的启动脚本,没找到有啥错误... 显然,你以为这是我等非专业人士写的吗?怎么可能有错??

最后,我只好在脚本中处处加上echo语句进行调试... 查看到底是什么条件没满足,导致statd无法正常启动

结果...最终...到头来,我发现是network配置文件中,不知道是哪个悲催的人士...把NETWORKING参数的参数名写错了,变成了NETWORING...

枉我杯具了一下午... 



Link URL: http://echo.sharera.com/blog/BlogTopic/73639.htm

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26127/viewspace-676117/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 09年丽江行花絮
下一篇: 疯狂煮妇出山记
请登录后发表评论 登录
全部评论

注册时间:2009-02-08

  • 博文量
    47
  • 访问量
    27157