為什麼 Fedora 會啟動 rpc-statd-notify.service 而不是 rpc-statd.service？
我注意到
rpc-statd-notify.service是在我的 Fedora 28 Workstation 筆記型電腦上啟動的。這似乎只是因為
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 服務：
- 簡訊通知
在本地系統重新啟動後通知 NFS 對等方的幫助程序
- rpc.statd
監聽來自其他主機的重啟通知的守護程序，並管理本地系統重啟時要通知的主機列表
本地 NFS 鎖管理器會提醒其本地 rpc.statd 應該監視的每個遠端對等點。當本地系統重啟時，sm-notify 命令會通知被監控對等體上的 NSM 服務重啟。當遠端重新啟動時，該對等方會通知本地 rpc.statd，而後者又會將重新啟動通知傳遞回本地 NFS 鎖管理器。
我想知道，Fedora 是否有理由預設支持重新啟動 NFSv3 客戶端系統，但不支持重新啟動伺服器系統？即重新啟動伺服器將打破客戶端持有的鎖。聽起來這可能是一個令人討厭的疏忽。
如果需要，顯然
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