DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8395C20881
From:   NeilBrown <neilb@suse.com>
To:     Steve Dickson <SteveD@RedHat.com>
Date:   Mon, 03 Dec 2018 11:58:25 +1100
Subject: [PATCH 3/3] systemd: run statd-notify even when nfs-client isn't
 enabled.
Cc:     Justin Mitchell <jumitche@rehat.com>, linux-nfs@vger.kernel.org
Message-ID: <154379870500.3215.3980663938514502057.stgit@noble>
In-Reply-To: <154379862296.3215.11174339731963464375.stgit@noble>
References: <154379862296.3215.11174339731963464375.stgit@noble>
User-Agent: StGit/0.17.1-dirty
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

When NFS filesytems are mounted, nfs-client.target really should
be enabled.  However it is possible to mount NFS filesystems
without this (providing gss isn't used) and it mostly works.

One aspect that doesn't work is that sm-notify isn't run, so the server
isn't told to drop any locks from the previous client instance.
This can result in confusing failures: if a client crashes while
holding a lock, it won't be able to get the same lock after a reboot.

While this isn't a complete solution (nfs-client really should be
enabled), adding a dependency from rpc-statd to rpc-statd-notify is
easy, has no down sides, and could help avoid confusion.

Signed-off-by: NeilBrown <neilb@suse.com>
---
 systemd/rpc-statd.service |    1 +
 1 file changed, 1 insertion(+)

diff --git a/systemd/rpc-statd.service b/systemd/rpc-statd.service
index 1f4e6a8b92ab..3e92cf71add0 100644
--- a/systemd/rpc-statd.service
+++ b/systemd/rpc-statd.service
@@ -4,6 +4,7 @@ DefaultDependencies=no
 Conflicts=umount.target
 Requires=nss-lookup.target rpcbind.socket
 Wants=network-online.target
+Wants=rpc-statd-notify.service
 After=network-online.target nss-lookup.target rpcbind.socket
 
 PartOf=nfs-utils.service