Re: [PATCH/RFC: nfs-utils] Common systemd unit files for nfs-utils.

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 4810 bytes --]

On Tue, 04 Feb 2014 13:26:42 -0500 Steve Dickson <SteveD@redhat.com> wrote:

> 
> 
> On 02/03/2014 05:34 PM, NeilBrown wrote:
> > On Mon, 03 Feb 2014 16:01:21 -0500 Steve Dickson <SteveD@redhat.com> wrote:

> > 
> > 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.
> In the beginning the .service suffix was not appended either. I actually
> opened a bug asking for the .service to be appended, which got
> soundly closed as NOTABUG! But I guess enough people bitched about
> so one day that "feature" just appeared. ;-)

Oh dear.  That is a sad story.  Good to know though.


> > 
> > 
> >>
> >> 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.
> I was thinking nfs-server would only start rpc.svcgssd when its
> enabled... not every time... 

I don't follow what you are saying ... not that it really matters as we both
seem to be agreed to take a different approach with the gss daemons.

In my original plan:
 if nfs-secure is enabled, then whenever nfs-server is started, it makes sure
 that rpc.svcgssd is running.
 if nfs-secure is not enabled, then rpc.svcgssd will refuse to start.


> 
> > Also rpc.gssd will be run whenever nfs-server.target or nfs-client.target is
> > started.
> Why is rpc.gssd started when the nfs server is started? Possibly for secure 
> loopback mounts??

Call-backs from NFSv4.0 server, as has been mentioned elsewhere.

> 
> > 
> >>
> >> 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?

No, the only way the .target files are more awkward is that you have to type
".target".

In fact a .target can be turned into an .service by adding:

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

at the end.  You might even get away with less than that.
Given this and that ".target" is extra typing, there seems little reason to
use .target unit files.

> 
> > 
> > 
> >>
> >>> +
> >>> + 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?
> Well in Fedora nfs-secure is one process ;-) 

Oh yes, "nfs-secure" means "run rpc.gssd".
If you wanted to preserve that I think you could create a drop-in file
for rpc-gssd.service containing
   [Install]
   Alias=nfs-secure.service
though that would require "systemctl enable rpc-gssd" so maybe it isn't the
best approach.


> 
> > 
> > I'm fairly sure we can keep that API working if you really need it, but
> > maybe as a fedora-specific hack?
> Yup! At the time I didn't know how to handle the security daemons
> that why there is a nfs-secure service and an nfs-server-secure
> service. 
> 
> The path we are head is much better... 

Glad you think so :-)

NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]