Comment # 19 on bug 990356 from jc sl

(In reply to Neil Brown from comment #18)
> Once you get nfs-client 1.3.4 installed, those changes should stay.
> The delays caused by rpcbind not running should be in the next kernel
> update, though I don't know how the timetable for that works.
> 

Ok, I'll wait until it is released.

> rpc.statd:
>             Starting NFS status monitor for NFSv2/3 locking...
> 
> will always be started by default, but it will fail if rpcbind isn't
> running.  A failure of rpc.statd won't cause nfsdv4 to fail.
> 

Out of curiosity, why is it started unconditionally?

> You probably have rpcbind.service still enabled.  I'm not sure if you did
> that or some system thing did.  Anyway, if you
>   systemctl disasble rpcbind.server
> and keep rpcbind.socket masked, it should start at all.  Then "NFS status
> monitor" won't successfully start either, but nfsd will.

Yes, rpcbind.service was enabled. At this point I don't know whether it was the
default or I changed it. Once disabled the "Starting NFS status monitor..."
message still is shown and fails, and the boot delay gets back. So I'll leave
it enabled until the updated packages appear.