On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 01/30/2014 01:24 AM, NeilBrown wrote: > > > > So: > > 1/ Do you agree that a collection of systemd unit files belongs in > > nfs-utils? > I think having a single way to start NFS across all distors would be > a very good thing... > > > 2/ Do you think it reasonable to expect most (systemd using) distros to > > use the one set? I will certainly try to ensure openSUSE does if > > upstream accepts them. > I think I'll already agreed to this as well... > > > 3/ Do you have any comments/question about those below? > I took a little closer look at these and actual tried to > get them to work in a Fedora environment. Here is what I found.. > > > > diff --git a/systemd/README b/systemd/README > > new file mode 100644 > > index 000000000000..f0fb68825499 > > --- /dev/null > > +++ b/systemd/README > > @@ -0,0 +1,50 @@ > > + > > +Notes about systemd unit files for nfs-utils. > > + > > +The unit files provided here should be sufficient for systemd > > +to manage all daemons and related services provides by nfs-utils. > > + > > +They do *not* include any unit files for separate services such as > > +rpc.rquotad (in the 'quota' package) or rpcbind. > > + > > +There are 4 units that can be 'enabled' or 'disabled' by systemctl, or > > +by a suitable 'preset' setting: > > + > > + nfs-server.target > > + If enabled, nfs service is started together with dependencies > > + such as mountd, statd, rpc.idmapd > This changes the current API... Today to enable/start this service > today one does: > > systemctl enable nfs-server > systemctl start nfs-server > > which would change to: > > systemctl enable nfs-server.target > systemctl start nfs-server I think this would need to be "systemctl start nfs-server.target". > > with the same daemons being started. > This changed will cause existing scripts to fail... > I guess I don't see the point of having a .target file. It's frustrating that "foo" is treated as "foo.service" rather than "foo.target" but I guess we have to live with it. According to the documentation a .service file "encodes information about a process controlled and supervised by systemd." nfs-server isn't "a process", it is a collection of processes. A .target is "used for grouping units" so it makes sense to me to group all the nfs-server units in an "nfs-server.target". So the structure makes sense based on the documentation and apparent design of systemd. Unfortunately it leads to this clumsy API of having to give the ".target" suffix. I guess it makes sense to merge nfs-server.service and nfs-server.target as, after all, nfs-server.service doesn't describe a process controlled by systemd anyway - it is a 'oneshot'.... I'll send a patch to do that. > > How is rpc.svcgssd enabled? Since the .service file does > not have a [Install] section the systemctl enable rpc.svcgssd > fails. The "README" touches on this. If you systemctl enable nfs-secure.target then rpc.svcgssd will be run whenever nfs-server.target is started. Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is started. > > Also how does gss-proxy come to play in all this? Maybe we > just use gss-proxy by default and retire rpc.svcgssd. I haven't really be following and so am only dimly aware of gss-proxy. It's a replacement for rpc.svcgssd - right? So we should get it to start in the same circumstances as rpc.svcgssd? Is there some easy test - eg something existing in the filesystem - that we could use to see if the kernel supports gss-proxy ? Also, I've been wondering if we could avoid the need to explicitly enable the gss stuff by gating it on the existence of /etc/krb5.keytab. Do you think that would be reasonable? > > > + > > + nfs-client.target > > + If enabled, daemons needs for an nfs client are enabled. > > + This does *not* include rpc.statd. the rpc-statd.service unit > > + is started by /usr/sbin/start-statd which mount.nfs will run > > + if statd is needed. > I am coming around to liking this one... but I think it should start > statd and configure lockd. Why not just roll the current nfs-lock > service under this umbrella? A simple systemctl restart nfs-client > would configure and start all of the needed daemons. I just feels like the wrong place to be setting sysctl values... But maybe. And why start statd if it isn't needed. > > 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. > > > + > > + nfs-secure.target > > + If enabled, then rpc.gssd will be run when either -client or > > + -server is started, and rpc.svcgssd will be run when -server > > + is started > I like that fact that rpc.gssd is started by nfs-client but > I don't like that API change. systemctl restart nfs-secure breaks Why would you want to "restart nfs-secure". I can understanding wanting to restart individual processed, or the whole collection, but why that subset? I'm fairly sure we can keep that API working if you really need it, but maybe as a fedora-specific hack? > > > + > > + nfs-blkmap.target > > + If enabled, then blkmapd will be run when nfs-client.target is > > + started. > Unless someone steps up and says why this is needed or if it will > ever be needed... I'm seriously thinking about dropping it from Fedora. > > I think overall its workable but I just don't see the advantage > of using .targets over .service files... > > steved. Thanks for your very thorough review. NeilBrown
Attachment:
signature.asc
Description: PGP signature
