linux – 什么是启动所有这些rpc.statd进程?

前端之家收集整理的这篇文章主要介绍了linux – 什么是启动所有这些rpc.statd进程?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我们的服务器上 – 运行CentOS 6 x86_64 – 我们看到很多关于rpc.statd的异常活动.我们将rpc.statd配置为通过/ etc / sysconfig / nfs在静态端口上运行:
MOUNTD_PORT=892
STATD_PORT=662
QUOTAD_PORT=875

这确实导致rpc.statd按预期运行和侦听此端口:

# ps -fe | grep rpc.statd | grep 662
rpcuser  23129     1  0 Apr30 ?        00:00:00 rpc.statd -p 662

奇怪的是,在这个系统上,还有许多其他的rpc.statd实例与–no-notify标志一起运行:

rpcuser    808     1  0 02:23 ?        00:00:00 rpc.statd --no-notify
rpcuser   2052     1  0 07:17 ?        00:00:00 rpc.statd --no-notify
rpcuser   3558     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   5787     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   6499     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser   8834     1  0 03:21 ?        00:00:00 rpc.statd --no-notify
rpcuser   9661     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  13702     1  0 00:08 ?        00:00:00 rpc.statd --no-notify
rpcuser  14813     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  15375     1  0 08:39 ?        00:00:00 rpc.statd --no-notify
rpcuser  15376     1  0 04:26 ?        00:00:00 rpc.statd --no-notify
rpcuser  19782     1  0 09:36 ?        00:00:00 rpc.statd --no-notify
rpcuser  20491     1  0 05:36 ?        00:00:00 rpc.statd --no-notify
rpcuser  23136     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  23320     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  26145     1  0 10:10 ?        00:00:00 rpc.statd --no-notify
rpcuser  26480     1  0 06:24 ?        00:00:00 rpc.statd --no-notify
rpcuser  26598     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify
rpcuser  26821     1  0 01:15 ?        00:00:00 rpc.statd --no-notify
rpcuser  28255     1  0 Apr30 ?        00:00:00 rpc.statd --no-notify

同样奇怪的是,其中一个过程显然已经篡夺了
关于rpcbind的原始rpc.statd进程.运行
rpcinfo报告以下端口的statd:

# rpcinfo -p
...
100024    1   udp  34322  status
100024    1   tcp  41686  status

这些对应于PID 26145(你可以看到其中一个
来自ps)的上述输出中的rpc.statd实例.

如果一切正常,这不会是一个问题,但昨天
系统开始遇到NFS挂载问题……任何尝试
挂载一个新的文件系统会导致:

mount.nfs: mount system call Failed

杀掉所有rpc.statd服务“解决”了这个问题,但是
我们对这里发生的事情感到困惑.我们从未见过这个
在我们类似配置的CentOS 5系统上的行为.

解决方法

好吧,这似乎是我们的错,部分是RedHat的authconfig命令中的错误.我们的Puppet配置导致authconfig –updateall每小时运行一次.这是不必要的,但通常它不应该是一个问题…除了authconfig重新启动rpcbind服务.

重新启动rpcbind会导致它忘记已向其注册的所有服务.然后authconfig将重新启动与NIS相关的服务,这会导致rpc.statd仍然在运行但不再向rpcbind注册的情况 – 这使得从尝试通过rpcbind找到它的应用程序的角度来看,它实际上是不可见的.

我修复了我们的Puppet配置,以便它不再像这样调用authconfig,并且我已经用RedHat打开了bug 818246.

原文链接:https://www.f2er.com/linux/396341.html

猜你在找的Linux相关文章