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 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. How is rpc.svcgssd enabled? Since the .service file does not have a [Install] section the systemctl enable rpc.svcgssd fails. Also how does gss-proxy come to play in all this? Maybe we just use gss-proxy by default and retire rpc.svcgssd. > + > + 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. How would these daemons be restart and shutdown? Since this is a target, systemctl restart and system stop don't do anything. > + > + 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 > + > + 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
