Re: [PATCH 1/2] nfs-service: Added the starting of gssproxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

That is exactly the rule that I (tried to) encode in the service file with
these two conditions.

NeilBrown

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux