Re: [PATCH v2] systemd: rpc-statd-notify.service can run in the background

[Tom Talpey <tom@talpey.com>]

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
>