Hey, On 06/21/2016 11:47 AM, Chuck Lever wrote: >>> >> 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. Well when rpc.gssd is not running (aka no upcalls) the delays stop happening. > > Are you saying that each negative reply takes a moment? Yes. Even on sec=sys mounts. Which is the issue. > 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? I don't think so... unless we start caching negative negative response or something like which is way overkill especially since the problem is solved by not starting rpc.gssd. > > Adding administrative interface complexity to work around > an underlying implementation problem might not be the best > long term choice. Well there already was way to stop gssd from starting when kerberos is configured but not for NFS. From the systemd/README: 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 containing [Unit] ConditionNull=false Which does work and will still work... but I'm thinking it is much similar to disable the service via systemd command systemctl disable rpc-gssd than creating and editing those .conf 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
