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

[Andreas Hasenack]

Still digging into some history, found this patch in the package:

debian/patches/27-systemd-enable-with-systemctl-statd.patch
Description: Let sysadmins enable/disable statd services
 As the admin was able to control under upstart the statd services with
 NEED_STATD in default conffiles, mirror this funcationality under systemd
 by letting the user systemctl enable/disable statd services.
Author: Didier Roche <didrocks at ubuntu.com>
Bug-Ubuntu: https://launchpad.net/bugs/1428486

Which removes the Wants for rpc-statd in nfs-server.service:
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -4,8 +4,7 @@ DefaultDependencies=no
 Requires= network.target proc-fs-nfsd.mount
 Requires= nfs-mountd.service
 Wants=rpcbind.socket
-Wants=rpc-statd.service nfs-idmapd.service
-Wants=rpc-statd-notify.service
+Wants=nfs-idmapd.service


Apparently starting statd or not was controlled by a NEED_STATD var in /etc/default, and that is gone. To not always start statd (because it's not needed in nfsv4 I guess), they removed it from Wants, and let it be controlled via its unit file. That patch is from 2015.

Looks like the final paragraph of your comment #8 was right on the spot.

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