Re: nfsdctl: lockd configuration failure reported after updating to nfs-utils-2.8.3

[Salvatore Bonaccorso <carnil@debian.org>]

Hi Jeff,

On Sat, Apr 26, 2025 at 08:49:36AM -0400, Jeff Layton wrote:
> On Sat, 2025-04-26 at 13:53 +0200, Salvatore Bonaccorso wrote:
> > Hi Jeff,
> > 
 
> > On Sat, Apr 26, 2025 at 06:55:42AM -0400, Jeff Layton wrote:
> > > On Sat, 2025-04-26 at 10:12 +0200, Salvatore Bonaccorso wrote:
> > > > Hi
> > > > 
> > > > After updating in Debian nfs-utils to 2.8.3, a systemctl status
> > > > nfs-server.service shows:
> > > > 
> > > > nfsdctl: lockd configuration failure
> > > > 
> > > > For reproducing the case the nfs.conf is kept to the default
> > > > (commented) section. 
> > > > 
> > > > In Debian we do not use the system linux/lockd_netlink.h (where the
> > > > changes only seem to have merged upstream in 6.15-rc1) and use the
> > > > shipped copy in nfs-utils instead.
> > > > 
> > > > I do not see problems with mounts, so I suspect the problem a user
> > > > reported downstream in https://bugs.debian.org/1104096 is just
> > > > cosmetical?
> > > > 
> > > > nfsdctl nlm reports:
> > > > 
> > > > nfsdctl: nfsd not found
> > > > 
> > > 
> > > The errors are harmless. They just means that you're running a new
> > > version of nfs-utils on top of an old kernel that doesn't have the
> > > netlink control interfaces for knfsd. The systemd service will fall
> > > back to starting the server with the legacy rpc.nfsd program if that
> > > fails so everything should still work after that.
> > 
> > Thanks for the confirmation. This aligns with what I found while
> > experimenting, and yes for me all works still after that on the system
> > with the exports.
> > 
> > We are running 6.12.y in Debian trixie, but having 2.8.3 available
> > already, so yes this has not the new interfaces.
> > 
> > I wonder if you will still count that as regression as before in 2.8.2
> > a nfsdctl autostart would bring still up the nfsd's.
> > 
> > With 2.8.2 and the 6.12.y kernel:
> > 
> > root@sid:~# ps -C nfsd
> >     PID TTY          TIME CMD
> >    1842 ?        00:00:00 nfsd
> >    1843 ?        00:00:00 nfsd
> >    1844 ?        00:00:00 nfsd
> >    1845 ?        00:00:00 nfsd
> >    1846 ?        00:00:00 nfsd
> >    1847 ?        00:00:00 nfsd
> >    1848 ?        00:00:00 nfsd
> >    1849 ?        00:00:00 nfsd
> >    1850 ?        00:00:00 nfsd
> >    1851 ?        00:00:00 nfsd
> >    1852 ?        00:00:00 nfsd
> >    1853 ?        00:00:00 nfsd
> >    1854 ?        00:00:00 nfsd
> >    1855 ?        00:00:00 nfsd
> >    1856 ?        00:00:00 nfsd
> >    1857 ?        00:00:00 nfsd
> > root@sid:~# nfsdctl threads 0
> > root@sid:~# ps -C nfsd
> >     PID TTY          TIME CMD
> > root@sid:~# nfsdctl autostart
> > root@sid:~# ps -C nfsd
> >     PID TTY          TIME CMD
> >    1874 ?        00:00:00 nfsd
> >    1875 ?        00:00:00 nfsd
> >    1876 ?        00:00:00 nfsd
> >    1877 ?        00:00:00 nfsd
> >    1878 ?        00:00:00 nfsd
> >    1879 ?        00:00:00 nfsd
> >    1880 ?        00:00:00 nfsd
> >    1881 ?        00:00:00 nfsd
> >    1882 ?        00:00:00 nfsd
> >    1883 ?        00:00:00 nfsd
> >    1884 ?        00:00:00 nfsd
> >    1885 ?        00:00:00 nfsd
> >    1886 ?        00:00:00 nfsd
> >    1887 ?        00:00:00 nfsd
> >    1888 ?        00:00:00 nfsd
> >    1889 ?        00:00:00 nfsd
> > root@sid:~# uname -a
> > Linux sid 6.12.25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.25-1 (2025-04-25) x86_64 GNU/Linux
> > root@sid:~#
> > 
> > But after updating to 2.8.3 not. I wonder if the new interface can be
> > made at runtime be used if a new enough kernel is available and
> > otherwise fall back again to the 2.8.2 behaviour?
> > 
> > What do you think? (I can as well ask the same just on the public
> > thread if we want to have a public record on linux-nfs list).
> > 
> 
> Sorry about the private reply. I just mashed the wrong button in my
> MUA.

Thanks for confirming, since nothing private will include the public
list again to have the answer documented, thanks a lot again for your
insights and explanation.

> Actually this is probably a bugfix and the earlier autostart
> functioning was a regression. The older nfsdctl version just ignored
> [lockd] parameters in nfs.conf and wouldn't configure it properly. So
> it started nfsd, but lockd wouldn't have gotten the right port settings
> or the configured gracetime.

Ok so likely not a regression from 2.8.2 -> 2.8.3 but actually a
bugfix.

> If you don't have any [lockd] settings, then nfsdctl should still work
> with no fallback to rpc.nfsd.

Actually it contains only the emtpy [lockd] stanza, but no explict
settings so just the defaults. But you are correct, if even comment
out the '[lockd]' from the default (as shipped upstream) then nfsdctl
autostart works as expected.

Thank you again for the swift replies, very much appreciated.

Regards,
Salvatore