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

[Charles Hedrick]

I conjecture that the problem occurred when moving from init scripts to
systemd. It's pretty clear that the default in the nfs-common init
script was to start statd. I conjecture that when converting to systemd,
someone forgot to put a Wants in nfs-server. It's got an after but not a
Wants. Writing the unit file with an [Install] section implies an
explicit enable, but you probably don't want that. You probably want
nfs-server to start it.

It wouldn't be easy to start it the first time a client mounts via NFS
3, without a kernel upcall, so I think nfs-common was right to default
to using it.

But it looks like nfs-common is a vestige of the init script days and
isn't used except in single user.

For what it's worth, centos 7 has a nearly identical unit file for rpc-
statd, except it's missing the [Install] section (presumably because
it's intended to be invoked by other things and not explicitly enabled).
There are Wants for autofs and nfs-server.

I think adding Wants to at least nfs-server makes sense.


rpc-statd.service doesn't have an install section

-- 
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