> On Jun 21, 2016, at 11:43 AM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > > On 06/21/2016 11:26 AM, Chuck Lever wrote: >> >>> On Jun 21, 2016, at 10:53 AM, Steve Dickson <steved@xxxxxxxxxx> wrote: >>> >>> When Kerberos is enabled, the /etc/krb5.keytab exists >>> which causes the both gssd daemons to start, automatically. >>> >>> With rpc.gssd running, on all NFS mounts, an upcall >>> is done to get GSS security context for SETCLIENTID procedure. >>> >>> When Kerberos is not configured for NFS, meaning >>> there is no host/hostname@REALM principal in >>> the key tab, those upcalls always fall causing >>> the mount to hang for several seconds. >> >> What is the root cause of the temporary hang? > All the upcalls to rpc.gssd... I think there are > three for every mount. > >> >> When you say "the upcall fails" do you mean there is >> no reply, or that there is a negative reply after a >> delay, or there is an immediate negative reply? > Good point.. the upcalls did not fail, they > just received negative replies. I would say that the upcalls themselves are not the root cause of the delay if they all return immediately. Are you saying that each negative reply takes a moment? If that's the case, is there something that gssd should do to reply more quickly when there's no host or nfs service principal in the keytab? Adding administrative interface complexity to work around an underlying implementation problem might not be the best long term choice. > steved. > >> >> >>> This patch added an [Install] section to both >>> services so the services can be enable and disable. >>> The README was also updated. >>> >>> Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> >>> --- >>> systemd/README | 14 +++++--------- >>> systemd/rpc-gssd.service | 6 ++++++ >>> systemd/rpc-svcgssd.service | 7 +++++++ >>> 3 files changed, 18 insertions(+), 9 deletions(-) >>> >>> diff --git a/systemd/README b/systemd/README >>> index 7c43df8..58dae42 100644 >>> --- a/systemd/README >>> +++ b/systemd/README >>> @@ -59,13 +59,9 @@ information such as in /etc/sysconfig/nfs or /etc/defaults/nfs. >>> It is run once by nfs-config.service. >>> >>> rpc.gssd and rpc.svcgssd are assumed to be needed if /etc/krb5.keytab >>> -is present. >>> -If a site needs this file present but does not want the gss daemons >>> -running, it should create >>> - /etc/systemd/system/rpc-gssd.service.d/01-disable.conf >>> -and >>> - /etc/systemd/system/rpc-svcgssd.service.d/01-disable.conf >>> +is present. If a site needs this file present but does not want >>> +the gss daemons running, they can be disabled by doing >>> + >>> + systemctl disable rpc-gssd >>> + systemctl disable rpc-svcgssd >>> >>> -containing >>> - [Unit] >>> - ConditionNull=false >>> diff --git a/systemd/rpc-gssd.service b/systemd/rpc-gssd.service >>> index d4a3819..681f26a 100644 >>> --- a/systemd/rpc-gssd.service >>> +++ b/systemd/rpc-gssd.service >>> @@ -17,3 +17,9 @@ EnvironmentFile=-/run/sysconfig/nfs-utils >>> >>> Type=forking >>> ExecStart=/usr/sbin/rpc.gssd $GSSDARGS >>> + >>> +# Only start if the service is enabled >>> +# and /etc/krb5.keytab exists >>> +[Install] >>> +WantedBy=multi-user.target >>> + >>> diff --git a/systemd/rpc-svcgssd.service b/systemd/rpc-svcgssd.service >>> index 41177b6..4433ed7 100644 >>> --- a/systemd/rpc-svcgssd.service >>> +++ b/systemd/rpc-svcgssd.service >>> @@ -18,3 +18,10 @@ After=nfs-config.service >>> EnvironmentFile=-/run/sysconfig/nfs-utils >>> Type=forking >>> ExecStart=/usr/sbin/rpc.svcgssd $SVCGSSDARGS >>> + >>> +# Only start if the service is enabled >>> +# and /etc/krb5.keytab exists >>> +# and when gss-proxy is not runing >>> +[Install] >>> +WantedBy=multi-user.target >>> + >>> -- >>> 2.5.5 >>> >>> -- >>> 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 >> >> -- >> Chuck Lever -- Chuck Lever -- 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
