On Tue, 23 Sep 2014 11:42:29 +1000 NeilBrown <neilb@xxxxxxx> wrote: > On Mon, 22 Sep 2014 16:00:50 -0400 Simo Sorce <simo@xxxxxxxxxx> wrote: > > > On Mon, 22 Sep 2014 15:53:46 -0400 > > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > > > > > > > > > On 09/22/2014 03:46 PM, Simo Sorce wrote: > > > > On Mon, 22 Sep 2014 15:40:57 -0400 > > > > "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > > > > > > > >> On Mon, Sep 22, 2014 at 03:20:07PM -0400, Steve Dickson wrote: > > > >>> Added the gssproxy.service to both the Wants= and > > > >>> Atfers= lines, before the rpc-svcgssd.service. There > > > >>> are ConditionPathExists= lines in the rpc-svcgssd.service > > > >>> unit which will stop the rpc.svcgssd daemon from > > > >>> starting when the gssproxy daemon is already running. > > > >> > > > >> That should read "when the kernel supports gssproxy", not > > > >> "when the gssproxy daemon is already running." > > > > > > > > Actually the language is currently correct but it is another > > > > bug, the systemd/rpc-svcgssd.service file still includes > > > > "ConditionPathExists=|!/run/gssproxy.pid" > > > > This line should be removed in this patch. > > > > > > I left that on purpose because isn't that ConditionPathExists > > > seeing if /run/gssproxy.pid exists and if it does > > > it means gssproxy is already running so rpc.svcgssd > > > should not start? > > > > No. > > First of all the fact gss-proxy is running does not mean it is > > serving nfsd necessarily, it may be running on an older kernel > > where it servers apache or some other process (remember gssproxy is > > not just for nfsd). > > Second you already have > > "ConditionPathExists=|!/proc/net/rpc/use-gss-proxy" which is the > > correct trigger to decide which of the two to use. > > > > 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? At the moment it is not, as there is no ordering between the 2 starting /run/gssproxy.pid may simply not be available "yet", also if it is available it doesn't mean rpc.svcgssd should not start. GSS-Proxy may be running but /proc/net/rpc/use-gss-proxy may not be present. So in general gssproxy.pid is not an indication of whether rpc.svcgssd should start or not. > That is exactly the rule that I (tried to) encode in the service file > with these two conditions. Then you also need to add After: gssproxy.service to rpc-svcgssd.service so you give it a chance to start and create the pid file. But again the mere existence of the pid file is not enough if the proc file is not there. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
