* Re: nfsdctl: lockd configuration failure reported after updating to nfs-utils-2.8.3
[not found] ` <a99a35da06712b9337913bb90e647447fdfefe51.camel@kernel.org>
@ 2025-04-26 20:17 ` Salvatore Bonaccorso
0 siblings, 0 replies; 2+ messages in thread
From: Salvatore Bonaccorso @ 2025-04-26 20:17 UTC (permalink / raw)
To: Jeff Layton; +Cc: Steve Dickson, linux-nfs
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
^ permalink raw reply [flat|nested] 2+ messages in thread