> On Jun 21, 2016, at 1:20 PM, Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > 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. Well let me say it a different way: the mechanism of performing an upcall should be fast. The stuff that gssd is doing as a result of the upcall request may be taking longer than expected, though. If gssd is up, and has nothing to do (which I think is the case here?) then IMO that upcall should be unnoticeable. I don't expect there to be any difference between the kernel squelching an upcall, and an upcall completing immediately. >> Are you saying that each negative reply takes a moment? > Yes. Even on sec=sys mounts. Which is the issue. Yep, I get that. I've seen that behavior on occasion, and agree it should be addressed somehow. >> 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. I'd like to understand why this upcall, which should be equivalent to a no-op, is not returning an immediate answer. Three of these in a row shouldn't take more than a dozen milliseconds. How long does the upcall take when there is a service principal versus how long it takes when there isn't one? Try running gssd under strace to get some timings. Is gssd waiting for syslog or something? >> 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. This should all be automatic, IMO. On Solaris, drop in a keytab and a krb5.conf, and add sec=krb5 to your mounts. No reboot, nothing to restart. Linux should be that simple. -- 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
