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

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

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

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

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

@H_301_2@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:

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

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

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

@H_301_2@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相关文章