有天同事问了我一个很奇怪的问题，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...

枉我杯具了一下午...