Re: git: 79d0f4474653 - main - rpcbind: Ensure krpc is present.

On Tue, Jun 10, 2025 at 07:28:15PM +0200, Dag-Erling Smørgrav wrote:
> Rick Macklem <rick.macklem@gmail.com> writes:
> > Gleb Smirnoff <glebius@freebsd.org> writes:
> > > Konstantin Belousov <kostikbel@gmail.com> writes:
> > > > Apparently we already have the feature called 'warmstart', where rpcbind
> > > > can be restarted and existing registrations are reloaded.  So it is in
> > > > fact already solved, assuming admin is careful enough to use -w.
> > > I really don't have a strong opinion on what would be right here.  I have no
> > > idea on how wide is the use of rpcbind w/o NFS.  Kostik, Rick and Dag-Erling,
> > > may you together come to agreement on what is right here?
> > I don't have a strong opinion on it either, since most kernel configs
> > include NFS options, so the krpc is there anyhow.
> 
> It is not in fact “already solved”, and I'm frankly disgusted at the
> amount of energy being spent on bikeshedding this after the fact
> compared with the complete lack of interest in the problem prior to my
> commit.
> 
> Not everybody runs GENERIC.
Right.

> Practically nobody uses NIS.
Wrong.

> Something
> needs to ensure that krpc is loaded when rpcbind starts in nearly 100%
> of rpcbind use cases.  My original choice was a small change to the rc
> script, but Rick insisted on doing it directly in rpcbind instead,
> although he now conveniently washes his hands of it.
> 
> Konstantin, I don't care how you solve this, but I need NFS to work, and
> I don't ever want to see “netlink: could not create service” on my
> console again.

And I do not want to get a host that cannot be logged in because rpcbind
exited with an error that krpc cannot be loaded, thus making NIS nss
unoperational.

This happens somewhere not on my local machines, I would indeed not use
NIS at home.  Changing all fleet there because the proper fix is considered
bikeshed is not feasible.