Re: [PATCH 0/2] nfs-utils: systemd units bug fixes and comments.

[NeilBrown <neilb@suse.de>]

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

On Tue, 18 Feb 2014 03:48:47 -0500 Steve Dickson <steved@redhat.com> wrote:

> Bug Fixes:
> 
> The /proc/net/rpc/use-gss-proxy file can not be used
> as a start up trigger for rpc.svcsgssd since it always
> exists, with or without gss-proxy installed.
> 
> Adding the Wants= to the nfs server unit cause a systemd ordering 
> cycle which caused reboots to take forever.
> 
> Comment One:
> 
> Even though nfs-client does conditionally start the rpc.gssd 
> service when /etc/krb5.keytab exists (which good), but that's 
> all it does. Meaning 'systemctl status' does not show that rpc.gssd 
> is running and 'systemctl restart' does not restart rpc.gssd 
> and 'systemctl stop' does not stop the daemon.

Well it doesn't *only* start rpc.gssd, it also starts e.g. sm-notify.  But
maybe you meant that.  It only starts things, it doesn't stop them.
This how systemd works.  Certainly there is no way I can see for 
   systemctl status foo
to report on anything but a single service: foo.  It might be nice if it
could report on a collection of services, but that doesn't seem to be
supported.

We could arrange that when you 'stop' nfs-client it would also stop rpc-gssd
(unless the server was running and wanted it) by setting
   StopWhenUnneeded=yes

That isn't the default in systemd so I'm cautious of setting it without a
good reason.  However I don't object if it turns out that it works.

Restart is a bit tricky - again because both the client and the server want
some services.
You can enable Restart propagation by using PartOf=.  However that also
enables Stop propagation and we don't want that.  i.e. we don't want 
   systemctl stop nfs-client
to unilaterally stop rpc.gssd - in particular not if nfs-server is running.


In short: I think that the inter-relationships in nfs-utils are too complex to
allow the simplicity that you are seeking.  Or systemd isn't sophisticated
enough to represent them.


> 
> It just seems odd to me that we will be using one target unit 
> to enable a daemon then another service unit (rpc-gssd) to 
> control it. 
> 
> I thinking we should  have one service unit, when enabled, control 
> both the rpc.gssd and the rpc.svcgssd daemons. The start up trigger 
> for both daemons will be the existence of /etc/krb5.keytab and 
> rpc.svcgssd will only be started if the nfs server is 
> enabled (if that is possible).

I originally thought that would not practical as the requirements for server
and client are different.  However I now see (thanks Bruce) that both the
client and the server need both rpc.gssd and rpc.svcgssd.  So we can have an
  nfs-secure
(or similar) which Wants both rpc-gssd and rpc-svcgssd.  Then both server and
client Want it.

However I don't think it should be "enabled".  It should automatically start
whenever nfs-server or nfs-client is started, providing the relevant files
exist.
(It can be 'masked' if someone has installed krb5 but really doesn't want the
gss daemons running).

So you would still use a different service to enable it than to restart it.

Also "systemctl status nfs-secure" would not be able to show you the status
of both daemons.

> 
> Comment Two:
> 
> How about renaming the nfs-utils unit to nfs-services since a 
> 'systemctl restart' of the unit start all the server and client 
> daemons (even when the server is not enabled, which is probably a bug).
> 

I don't object to a renaming.  The name "nfs-utils" was simply the first
thing I thought of.

  systemctl restart nfs-utils

should *not* start any service that is not already started.  I think I tested
that.  However if I'm wrong we could argue that "try-restart" should be used
if you don't want to start services that aren't already running.... though
I'm not sure that would work.  Must test....

 systemctl stop nfs-utils

should stop services.  It uses "PartOf" which is supposed to apply to
'restart' and 'stop' equally.


> Since a 'systemctl restart nfs-utils' starts all the daemons shouldn't
> 'systemctl stop nfs-utils' bring them all down as well?

Doesn't it?

> 
> Another oddity, going a 'systemctl restart nfs-utils' causes v3 
> mounts to go stale... Meaning going a ls on a v3 mount point 
> after the restart errors out with ESTALE... Not sure why... 
> 

That is weird and certainly needs looking in to.  I could be due to

   ExecStopPost=/usr/sbin/exportfs -au

I wonder if we really need that.

I hope to get some time tomorrow to experiment with all this and I will
definitely look into this issue (unless you explain it first :-)


> Comment Three:
> 
> I'm not seeing how the nfs-utils_env.sh file, called by each unit, 
> is all that useful. The main reason is you can not tell which 
> unit its being called from so how do know what should be done? 
> I guess I'm just missing the concept on how and what it should 
> be used for.

I've got a patch which changes this so it is only called once in a separate
service.  However the principle remains unchanged.

The purpose of the script is to read /etc/sysconfig/nfs (or similar) and
write out /run/sysconfig/nfs-utils containing *all* the environment variables
used in *any* nfs-utils unit file.  It allows a translation from what is
expected in the sysconfig file to what the daemons expect as their arguments.

I see this as a transitional thing.  Ultimately the various daemons should be
able to inspect their environment, and expect exactly the things that might
be in the config file. So systemd just reads /etc/sysconfig/nfs and then runs
the daemons.  But that goal is a little ways off yet.

One thing we have in our sysconfig file is "NFS3_SERVER_SUPPORT".  If that is
set to "no", then as well as constructing appropriate arguments for rpc.mountd
and rpc.nfs we don't run rpc.statd (unless a v3 filesystem is mounted).
Handling the first part with nfs-utils_env.sh is trivial.  Handling the
second bit is something I haven't figured out yet.

Thanks for your comments.

NeilBrown


> 
> Steve Dickson (2):
>   rpc-svcgssd.service: removed a the start up triggers
>   systemd: Removed the "ordering cycle" from nfs-server.service
> 
>  systemd/nfs-server.service  | 2 --
>  systemd/rpc-svcgssd.service | 1 -
>  2 files changed, 3 deletions(-)
> 


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