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

[Charles Hedrick]

Statd is used by both client and server. I think that note is for the
client usage.

Our servers don't necessariy do any NFS3 client mounts, so the client
start would't happen. Is it possible that at some point I mounted
something via NFS3 and that's the only reason statd was running? I can't
prove that that isn't true.

I tried enabling nfs-server and that didn't help.

My solution has been to enable rpc-statd explicitly. That works.

The reason I reported the problem is that it had previously worked
automatically, and it took me quite a while to figure out why after the
upgrade NFS 3 wasn't working on the server. I might not be alone in
this.

It looks like it's supposed to be started by /etc/init.d/nfs-common, but
I'm pretty sure that isn't started except in /etc/rcS.d/, which wouldn't
normally happen. I put a statement in nfs-common to create a file in
/var/log, and it didn't happen, so I don't believe nfs-common ran.

I suspect statd should be started as part of nfs-server, but it doesn't
seem to be happening. Unless you assume that people are just using nfs 4
and want to require manual intervention to support 3. I wouldn't expect
that. Particularly since the symptoms are subtle. If you try an NFS 3
mount it works. Things don't start failing until someone tries locking.
The most common case is probably firefox, thunderbird, etc, which lock
their profiles.

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

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