On Wed, Dec 19, 2018 at 07:19:53PM -0500, Jeff Layton wrote: > On Wed, 2018-12-19 at 17:11 -0500, Scott Mayhew wrote: > > On Wed, 19 Dec 2018, Jeff Layton wrote: > > > It seems like we probably ought to check to see if the daemon is up > > > before attempting a UMH upcall now? If someone starts up the daemon > > > they'll probably be surprised that it didn't get used because there was > > > a UMH upcall program present. > > > > I figured that the UMH upcall program would still be the default and > > that the admin would have to do some extra configuration to use nfsdcld, > > namely remove the /var/lib/nfs/v4recovery directory and set an empty > > value for nfsd's 'cltrack_prog' module option. Do you think that's a > > bad idea? > > > > -Scott > > > > The only real issue there is that that is several steps, any of which > someone could screw up. I think we probably do want to aim for allowing > someone to enable nfsdcld (via systemd or whatever) and have it all > "just work" without needing to do anything else. If we just care about being able to set this up for users, the rpm (or other package) install could remove /var/lib/nfs/v4recovery, drop a configuration file in /etc/modprobe.d to set cltrack_prog, and enable a systemd unit. But you're thinking somebody might want to switch a system back and forth? I guess that could be useful for debugging and, yeah the multiple steps would be more error prone. > Assuming that daemon works better and in more places than the umh > helper, should we aim for it to eventually become the default? I hope so. If we have to switch this again I'm going to quit and go into some other business.... --b.
