有天同事问了我一个很奇怪的问题,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/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/26127/viewspace-676117/