[Bug 1956787] Re: nfs v3 locking fails - rpc-statd not started after minor upgrade

[Andreas Hasenack]

I think the conclusion here is that on a focal server, if you expect to
server non-nfsv4 clients, you need to enable rpc-statd manually with
systemctl, and we should document it in the server guide
(https://ubuntu.com/server/docs/service-nfs).

Unless there is a trivial way to change this that for sure won't impact
other scenarios, I'm wary of touching the systemd unit files in such a
fashion on an LTS release, for fear of introducing other bugs or
regressions, specially because this behavior was specifically introduced
by a debian/ubuntu patch.

On the flip side, the reasons for the patch might no longer exist
nowadays, so I think it's valid to revisit this for the upcoming LTS
release, 22.04. In fact, quickly looking at the nfs-utils package in
debian/experimental shows they apparently dropped this patch already:

nfs-utils (1:2.5.4-1~exp5) experimental; urgency=medium
...
  * Drop "Let sysadmins enable/disable statd services"
...
 -- Salvatore Bonaccorso <carnil at debian.org>  Tue, 14 Sep 2021 09:48:58 +0200

So that's my plan:
- document that rpc-statd might have to be manually enabled (note that even a focal nfs client will default to nfsv4.2, not requiring statd on the server nor the client)
- close this bug for focal
- see what we can do for jammy (22.04)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to nfs-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1956787

Title:
  nfs v3 locking fails - rpc-statd not started after minor upgrade

Status in nfs-utils package in Ubuntu:
  Confirmed

Bug description:
  We just upgraded our nfs servers from 5.4.0-72 to 5.4.0-92.

  We are using NFS v3 in a large computer science department, with
  several hundred clients.

  Lots of applications are now failing because locks don't work.

  /var/log/syslog on the client reports lockd not responding. tcpdump
  shows that the client tries to connect to lockd but there is no
  response to the TCP SYN.

  netstat on the server shows some connections open, with lots of bytes
  in the receive queue.

  The problem probably occurs only with lots of clients. I believe any
  typical test would work fine.

  The problem is new. That is, it didn't happen in 5.4.0-72.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: kernel-common (not installed)
  ProcVersionSignature: Ubuntu 5.4.0-92.103-generic 5.4.157
  Uname: Linux 5.4.0-92-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu27.21
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Fri Jan  7 13:07:34 2022
  InstallationDate: Installed on 2020-10-14 (450 days ago)
  InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
  SourcePackage: kernel-package
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.default.apport: [modified]
  mtime.conffile..etc.default.apport: 2020-10-14T13:53:33.474467

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1956787/+subscriptions