☰

为什么 Fedora 会启动 rpc-statd-notify.service 而不是 rpc-statd.service？

tag-icon • tag-icon fedora nfs
为什么 Fedora 会启动 rpc-statd-notify.service 而不是 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 和版本 3，网络状态监视器协议（或简称 NSM）用于通知 NFS 对等方重新启动。在 Linux 上，两个独立的用户空间组件构成了 NSM 服务：

  • sm-通知

    本地系统重新启动后通知 NFS 对等方的帮助程序

  • rpc.statd

    一个守护进程，用于侦听来自其他主机的重新启动通知，并管理本地系统重新启动时要通知的主机列表

本地 NFS 锁管理器向其本地 rpc.statd 发出应监视的每个远程对等点的警报。当本地系统重新启动时，sm-notify 命令会通知受监控对等方上的 NSM 服务重新启动。当远程重新启动时，该对等方会通知本地 rpc.statd，后者又将重新启动通知传递回本地 NFS 锁定管理器。

我想知道，Fedora 是否默认支持重新启动 NFSv3 客户端系统，但不支持重新启动服务器系统，是否有原因？即重新启动服务器将打破客户端持有的锁。听起来这可能是一个令人恼火的疏忽。

答案1

如果需要的话，显然会安排按需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.target

答案2

看起来丢失rpc-statd会导致 NFS 客户端出现明显的故障。因此，管理员会注意到这一点，并在造成任何后果之前予以纠正微妙的锁定问题。

Jul 08 17:24:20 mount[957]: mount.nfs: rpc.statd 未运行，但远程锁定需要。 Jul 08 17:24:20 mount[957]: mount.nfs: 使用“-o nolock”将锁保持在本地，或者启动 statd。

https://forums.fedoraforum.org/showthread.php?292563-rpc-statd-starting-after-some-nfs-mounts

相比之下，丢失rpc-statd-notify很容易被忽视，这可能会导致服务器上持续存在不良影响（陈旧的锁）。所以也许有一些东西可以鼓励它被启用是件好事......

似乎不再有太多关于启动 NFSv3 的 Redhat 官方文档了（而且 Google 也没有极好的也有帮助）。旧文档传统上涉及启用一堆服务，并且 rpc.statd 守护进程往往会作为其中的一部分被提及。

但我怀疑这种不一致意味着人们仍然很可能启用 rpc-statd 并忽略启用 rpc-statd-notify 的需要。特别是因为看起来在早期，启动 rpc-statd 的服务可能已经完成了通知位本身 - 我看到 rpc-statd.service 正在设置RPC_STATD_NO_NOTIFY=1。

因此，如果nfs-client.target它没有自动启动，并且没有文档将其作为要启用的服务之一提及，那么上述理由似乎是站不住脚的。也许更好的解释是，它只是陈旧、被忽视和凌乱。

但这似乎也不是一个非常可靠的答案。在某个时刻一定有特定的原因不是只是让 rpc.statd 自己完成通知部分。

注意：sm-notify 命令包含一项检查，以确保它在每次系统重新启动后仅运行一次。如果 rpc.statd 在没有 [--no-notify] 选项的情况下重新启动，这可以防止虚假的重新启动通知。

相关内容