On Tue, 18 Feb 2014 03:48:47 -0500 Steve Dickson <steved@xxxxxxxxxx> 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:
signature.asc
Description: PGP signature
