为什么Fedora要启动rpc通知服务，而不启动rpc-statd.service？
我注意到rpc-statd-notify.service是在我的Fedora 28工作站笔记本电脑上启动的。
这似乎只是因为我的笔记本上启用了nfs-client.target。这是相当合理的，我使在过去的某个时间点。这回答了我的主要问题..。
但是我注意到，相比之下，rpc.statd不是在我的系统上启动的。这不会引起麻烦吗？
$ systemctl status rpc-statd-notify
● rpc-statd-notify.service - Notify NFS peers of a restart
Loaded: loaded (/usr/lib/systemd/system/rpc-statd-notify.service; static; vendor preset: disabled)
Active: active (exited) since Tue 2018-05-08 08:02:24 BST; 4h 55min ago
Process: 1451 ExecStart=/usr/sbin/sm-notify $SMNOTIFYARGS (code=exited, status=0/SUCCESS)
May 08 08:02:23 alan-laptop systemd[1]: Starting Notify NFS peers of a restart...
May 08 08:02:24 alan-laptop sm-notify[1451]: Version 3.1.1 starting
May 08 08:02:24 alan-laptop systemd[1]: Started Notify NFS peers of a restart.
$ systemctl list-dependencies --reverse rpc-statd-notify
rpc-statd-notify.service
● ├─nfs-server.service
● ├─nfs-utils.service
● └─nfs-client.target
● ├─multi-user.target
● └─remote-fs.target
[...]
$ systemctl status nfs-client.target
● nfs-client.target - NFS client services
Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled; vendor preset: disabled)
Active: active since Tue 2018-05-08 08:01:52 BST; 5h 28min ago
May 08 08:01:52 alan-laptop systemd[1]: Reached target NFS client services.man sm-notify
文件锁不是持久文件系统状态的一部分。因此，当主机重新启动时，锁状态将丢失。网络文件系统还必须检测由于远程主机重新启动而丢失锁状态的时间。NFS客户端重新启动后，NFS服务器必须释放运行在该客户端上的应用程序所持有的所有文件锁。服务器重新启动后，客户端必须提醒服务器注意运行在该客户端上的应用程序所持有的文件锁。对于NFS 2和version 3，使用网络状态监视器协议(简称NSM )通知NFS对等方重新启动。在Linux上，两个独立的用户空间组件构成NSM服务：
- sm-在本地系统重新启动后通知NFS对等方的帮助程序。
- rpc.statd守护进程侦听来自其他主机的重新启动通知，并管理本地系统重新启动时要通知的主机列表的守护进程。
本地NFS锁定管理器通知其本地rpc.statd每个应被监视的远程对等点。当本地系统重新启动时，sm- notifies命令将重新启动通知受监视的对等端上的NSM服务。当远程重新启动时，该对等点通知本地rpc.statd，而本地又将重新启动通知传递给本地NFS锁定管理器。
我想知道，Fedora为什么默认支持重新启动NFSv3客户端系统，而不支持重新启动服务器系统呢？也就是说，重新启动服务器将打破客户端持有的锁。听起来可能是个恼人的疏忽。
回答 2
Unix & Linux用户
发布于 2018-05-08 13:24:45
显然，如果需要的话，mount.nfs将安排按需启动rpc-statd.service。这可能避免了在rpc.statd客户机上启动NFSv4，因此这意味着没有不必要的资源使用等等。
$ systemctl cat nfs-client.target
# /usr/lib/systemd/system/nfs-client.target
[Unit]
Description=NFS client services
Before=remote-fs-pre.target
Wants=remote-fs-pre.target
# Note: we don't "Wants=rpc-statd.service" as "mount.nfs" will arrange to
# start that on demand if needed.
Wants=rpc-statd-notify.service
# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
After=rpc-gssd.service rpc-svcgssd.service gssproxy.service
[Install]
WantedBy=multi-user.target
WantedBy=remote-fs.targetUnix & Linux用户
发布于 2018-05-08 13:02:59
看起来，缺少rpc-statd会导致NFS客户端出现明显的故障。因此，管理员会注意到这一点，并在引起锁定的任何微妙问题之前进行更正。
七月08 17:24:20安装: mount.nfs: rpc.statd没有运行，但是远程锁定是必需的。七月08 17:24:20安装: mount.nfs:要么使用'-o nolock‘保持本地锁定，要么启动statd。
https://forums.fedoraforum.org/showthread.php?292563-rpc-statd-starting-after-some-nfs-mounts
相反，缺少的rpc-statd-notify很容易被忽略，这可能会导致服务器上持久存在不良的影响(陈旧的锁)。所以也许有一些东西鼓励它成为可能是很好的.
启动NFSv3的官方Redhat文档似乎已经不多了(谷歌也不是超级有用的)。传统上，旧的文档需要启用一组服务，而rpc.statd守护进程往往是其中的一部分。
但我怀疑这种不一致意味着人们仍然很可能启用rpc-statd，而忽略了启用rpc-statd-通知的需要。尤其是在早期，启动rpc-statd的服务可能已经完成了通知位本身-我看到rpc-statd.service正在设置RPC_STATD_NO_NOTIFY=1。
因此，如果nfs-client.target不是自动启动的，而且没有文档可以将其作为要启用的服务之一，那么上面的说明似乎是一个很弱的理由。也许更好的解释是，它只是老了，被忽视了，而且凌乱不堪。
不过，这似乎也不是一个非常可靠的答案。一定有一个特定的原因，不只是让rpc.statd自己做通知部分。
注意: sm-notify命令包含一个检查，以确保它在每个系统重新启动后只运行一次。如果rpc.statd在没有选项的情况下重新启动，这将防止虚假的重新启动通知。
https://unix.stackexchange.com/questions/442538
复制相似问题
腾讯云开发者
