On Wed, 5 Feb 2014 16:11:07 -0500 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Wed, Feb 05, 2014 at 04:43:51PM +1100, NeilBrown wrote: > > On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > > > > > > > > > >> > > > >> How would these daemons be restart and shutdown? Since this is a > > > >> target, systemctl restart and system stop don't do anything. > > > > > > > > This is something I haven't completely figured out yet. > > > > > > > > Part of the solution might be the "PartOf" directive. > > > > If each service claims to be "PartOf" the main one, then stopping or > > > > restarting the main service will propagate to stopping and restarting the > > > > individual services. > > > > Unfortunately in nfs we have some shared services. rpc.statd and rpc.gssd > > > > are needed by both server and client. That isn't a big problem for 'restart', > > > > but if you 'systemctl stop nfs-client' and find that the server isn't > > > > properly working any more, that would be awkward > > > > If could possibly work around that by setting "StopWhenUnneeded" for those > > > > shared services. Then e.g. rpc.statd would stop when both client and server > > > > are stopped, but not if either one of them is stopped. > > > > However I don't know how that interacts with restart. I suspect that the > > > > StopWhenUnneeded services are *not* stopped and restarted when the main > > > > service is stopped. So it would be hard to restart all nfs services on an > > > > upgrade. > > > > > > > > Further research seems needed here. > > > Fine... I'll try to digest what you are saying here, but > > > would it make it easier if everything was in a service file? > > > > So I did a bit more research and thinking, and I present the two patches > > below for consideration. If you agree and would prefer them in separate > > emails I can certainly do that. > > > > The first ensures that we can easily restart all daemons during software > > update. It creates a new 'nfs-utils.service' which exists only to allow that > > restart. > > > > The second ensures startup and shutdown work properly (though I haven't > > tested much). > > Do we need to shutdown nfs-server or nfs-client easily at any time other than > > system shutdown? > > I think it's hard to as I don't think there's a way for the NSM protocol > to treat the nfs client and server as different things that could go up > and down independently. But I could be wrong, I rarely think about > statd! In a v4-only setup that wouldn't be a problem any more. So if we don't make it particular easy to restart statd, then that might be a good thing? I can live with that :-) > > On the server side there are a few parameters (v4 lease time?) that can > only be changed with a restart but maybe that's not terribly important. Maybe this should be treated as 'reload'. If we provide ExecReload for nfs-server.service which: - stops the nfsd threads - updates all these parameters - optionally triggers a new grace period?? (or is that automatic) - start the nfsd threads we could document that "systemctl reload nfs-server" does the right thing > > HA people may restart the server on failover to get a new grace period. > They probably use their own scripts for that but it would be better to > get them using standard systemd configuration to the extent possible. Probably best not to second-guess such configurations if we don't thoroughly understand them - but if we hear of a need that our unit files don't meant we can use that as a trigger for improvement. > > Anyway those are existing problems that it's not necessarily up to you > to fix. True, but good to consider nonetheless. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
