On Tue, Sep 23, 2014 at 11:42:29AM +1000, NeilBrown wrote: > Surely gssproxy is only serving nfsd requests if both /run/gssproxy.pid > exists and /proc/net/rpc/use-gss-proxy exists. > If either of those files is missing, then rpc.svcgssd needs to run. > In one case, the gssproxy daemon isn't available for some reason. In the > other case the kernel cannot make use of it. > > Is that not correct? > > That is exactly the rule that I (tried to) encode in the service file with > these two conditions. Eh, I see your point, but the gssproxy.pid one still seems a little odd to me. I guess it's friendlier to people that don't have gss-proxy installed at all, or want to turn it off for some reason--but then they or their distro can fix up the unit files too. Otherwise if we've got gss-proxy and the kernel supports it then it should work, and if it's failing to come up in that case I'd kind of like to know why and get a bug report like "gssproxy failed to start" or "krb5 exports stopped working" rather than "krb5 exports are working in some subtly different way than they did last week." --b. -- 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