On 1/4/2021 1:55 PM, Hackintosh 5 wrote:
This allows rpc-statd-notify to run in the background when it is
only in use by a client. This is done by a timer unit with a one
second timeout, which is Wanted by nfs-client.target. The result
is that there is no longer a dependency on network-online.target
by multi-user.target, so everyone gets faster boot times yay.
I'm concerned that this change may allow the nfs client to start
before the sm-notify has a chance to send its "I'm back" message
to the server, and for the server to process it. This will lead
to lock failures.
Also, I'm unclear how an apparently arbitrary 1-second delay is
fixing this. Is this really a systemd thing? If so, changing the
NFS behavior is the wrong approach.
Tom.
---
systemd/nfs-client.target | 2 +-
systemd/rpc-statd-notify.timer | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 systemd/rpc-statd-notify.timer
diff --git a/systemd/nfs-client.target b/systemd/nfs-client.target
index 8a8300a1..b7cce746 100644
--- a/systemd/nfs-client.target
+++ b/systemd/nfs-client.target
@@ -5,7 +5,7 @@ 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
+Wants=rpc-statd-notify.timer
# GSS services dependencies and ordering
Wants=auth-rpcgss-module.service
diff --git a/systemd/rpc-statd-notify.timer b/systemd/rpc-statd-notify.timer
new file mode 100644
index 00000000..bac68817
--- /dev/null
+++ b/systemd/rpc-statd-notify.timer
@@ -0,0 +1,9 @@
+[Unit]
+Description=Notify NFS peers of a restart
+RefuseManualStart=true
+RefuseManualStop=true
+
+[Timer]
+OnActiveSec=1
+Unit=rpc-statd-notify.service
+RemainAfterElapse=false
