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

Commit Message

Steve Dickson Sept. 22, 2014, 7:20 p.m. UTC

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.

Signed-off-by: Steve Dickson <[e-mail]>
---
 systemd/nfs-server.service | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Simo Sorce Sept. 22, 2014, 7:26 p.m. UTC | #1

On Mon, 22 Sep 2014 15:20:07 -0400
Steve Dickson <[e-mail]> 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.
> 
> Signed-off-by: Steve Dickson <[e-mail]>
> ---
>  systemd/nfs-server.service | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> index 2fa7387..c740fa2 100644
> --- a/systemd/nfs-server.service
> +++ b/systemd/nfs-server.service
> @@ -2,12 +2,13 @@
>  Description=NFS server and services
>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>  Requires= nfs-mountd.service
> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> +Wants=rpc-gssd.service  
>  Wants=rpc-statd-notify.service
>  
>  After= network.target proc-fs-nfsd.mount rpcbind.target
> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> -After= rpc-gssd.service rpc-svcgssd.service
> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>  Before= rpc-statd-notify.service
>  
>  Wants=nfs-config.service

I think you really need to insure that the modules are loaded before
any of the server services are started, perhaps adding a unit file that
exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
in it ?

Simo.

J. Bruce Fields Sept. 22, 2014, 7:40 p.m. UTC | #2

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."

--b.

> 
> Signed-off-by: Steve Dickson <[e-mail]>
> ---
>  systemd/nfs-server.service | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> index 2fa7387..c740fa2 100644
> --- a/systemd/nfs-server.service
> +++ b/systemd/nfs-server.service
> @@ -2,12 +2,13 @@
>  Description=NFS server and services
>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>  Requires= nfs-mountd.service
> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
> +Wants=rpc-statd.service nfs-idmapd.service 
> +Wants=rpc-gssd.service gssproxy.service rpc-svcgssd.service
>  Wants=rpc-statd-notify.service
>  
>  After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
>  After= nfs-idmapd.service rpc-statd.service
> -After= rpc-gssd.service rpc-svcgssd.service
> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>  Before= rpc-statd-notify.service
>  
>  Wants=nfs-config.service
> -- 
> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steve Dickson Sept. 22, 2014, 7:43 p.m. UTC | #3

On 09/22/2014 03:26 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 15:20:07 -0400
> Steve Dickson <[e-mail]> 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.
>>
>> Signed-off-by: Steve Dickson <[e-mail]>
>> ---
>>  systemd/nfs-server.service | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
>> index 2fa7387..c740fa2 100644
>> --- a/systemd/nfs-server.service
>> +++ b/systemd/nfs-server.service
>> @@ -2,12 +2,13 @@
>>  Description=NFS server and services
>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>  Requires= nfs-mountd.service
>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
>> +Wants=rpc-gssd.service  
>>  Wants=rpc-statd-notify.service
>>  
>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
>> -After= rpc-gssd.service rpc-svcgssd.service
>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>>  Before= rpc-statd-notify.service
>>  
>>  Wants=nfs-config.service
> 
> I think you really need to insure that the modules are loaded before
> any of the server services are started, perhaps adding a unit file that
> exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
> in it ?
I really don't think its needed... From my testing it appears 
gssproxy is always being started and rpc.svcgssd is not... 

Plus, from my understanding...  loading module from a service 
file is a big no no! People were having problems with
way back when... 

steved.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 22, 2014, 7:46 p.m. UTC | #4

On Mon, 22 Sep 2014 15:40:57 -0400
"J. Bruce Fields" <[e-mail]> 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.

Simo.

> --b.
> 
> > 
> > Signed-off-by: Steve Dickson <[e-mail]>
> > ---
> >  systemd/nfs-server.service | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > index 2fa7387..c740fa2 100644
> > --- a/systemd/nfs-server.service
> > +++ b/systemd/nfs-server.service
> > @@ -2,12 +2,13 @@
> >  Description=NFS server and services
> >  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >  Requires= nfs-mountd.service
> > -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> > rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> > +Wants=rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >  Wants=rpc-statd-notify.service
> >  
> >  After= network.target proc-fs-nfsd.mount rpcbind.target
> > nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> > -After= rpc-gssd.service rpc-svcgssd.service
> > +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >  Before= rpc-statd-notify.service
> >  
> >  Wants=nfs-config.service
> > -- 
> > 1.9.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-nfs" in the body of a message to [e-mail]
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steve Dickson Sept. 22, 2014, 7:53 p.m. UTC | #5

On 09/22/2014 03:46 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 15:40:57 -0400
> "J. Bruce Fields" <[e-mail]> 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?

steved.

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 22, 2014, 8 p.m. UTC | #6

On Mon, 22 Sep 2014 15:53:46 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/22/2014 03:46 PM, Simo Sorce wrote:
> > On Mon, 22 Sep 2014 15:40:57 -0400
> > "J. Bruce Fields" <[e-mail]> 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.

Simo.

Steve Dickson Sept. 22, 2014, 8:02 p.m. UTC | #7

On 09/22/2014 04:00 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 15:53:46 -0400
> Steve Dickson <[e-mail]> wrote:
> 
>>
>>
>> On 09/22/2014 03:46 PM, Simo Sorce wrote:
>>> On Mon, 22 Sep 2014 15:40:57 -0400
>>> "J. Bruce Fields" <[e-mail]> 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.
Fair enough... that makes sense... 

steved.

> 
> Simo.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

J. Bruce Fields Sept. 22, 2014, 8:44 p.m. UTC | #8

On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> 
> 
> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> > On Mon, 22 Sep 2014 15:20:07 -0400
> > Steve Dickson <[e-mail]> 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.
> >>
> >> Signed-off-by: Steve Dickson <[e-mail]>
> >> ---
> >>  systemd/nfs-server.service | 5 +++--
> >>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> >> index 2fa7387..c740fa2 100644
> >> --- a/systemd/nfs-server.service
> >> +++ b/systemd/nfs-server.service
> >> @@ -2,12 +2,13 @@
> >>  Description=NFS server and services
> >>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>  Requires= nfs-mountd.service
> >> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> >> +Wants=rpc-gssd.service  
> >>  Wants=rpc-statd-notify.service
> >>  
> >>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> >> -After= rpc-gssd.service rpc-svcgssd.service
> >> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >>  Before= rpc-statd-notify.service
> >>  
> >>  Wants=nfs-config.service
> > 
> > I think you really need to insure that the modules are loaded before
> > any of the server services are started, perhaps adding a unit file that
> > exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
> > in it ?
> I really don't think its needed... From my testing it appears 
> gssproxy is always being started and rpc.svcgssd is not... 

Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as both
"Requires=" and "After=", so rpc-svcgssd.service will never run
without first running var-lib-nfs-rpc_pipefs.mount, which will load
sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
don't see what ensures anything happening before gssproxy runs.

We want to make sure your testing's not just getting lucky on the
startup order.

> Plus, from my understanding...  loading module from a service 
> file is a big no no! People were having problems with
> way back when... 

Any pointers?  Google's not finding me anything.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steve Dickson Sept. 22, 2014, 9:14 p.m. UTC | #9

On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
>>
>>
>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
>>> On Mon, 22 Sep 2014 15:20:07 -0400
>>> Steve Dickson <[e-mail]> 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.
>>>>
>>>> Signed-off-by: Steve Dickson <[e-mail]>
>>>> ---
>>>>  systemd/nfs-server.service | 5 +++--
>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
>>>> index 2fa7387..c740fa2 100644
>>>> --- a/systemd/nfs-server.service
>>>> +++ b/systemd/nfs-server.service
>>>> @@ -2,12 +2,13 @@
>>>>  Description=NFS server and services
>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>>>  Requires= nfs-mountd.service
>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
>>>> +Wants=rpc-gssd.service  
>>>>  Wants=rpc-statd-notify.service
>>>>  
>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
>>>> -After= rpc-gssd.service rpc-svcgssd.service
>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>>>>  Before= rpc-statd-notify.service
>>>>  
>>>>  Wants=nfs-config.service
>>>
>>> I think you really need to insure that the modules are loaded before
>>> any of the server services are started, perhaps adding a unit file that
>>> exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
>>> in it ?
>> I really don't think its needed... From my testing it appears 
>> gssproxy is always being started and rpc.svcgssd is not... 
> 
> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as both
> "Requires=" and "After=", so rpc-svcgssd.service will never run
> without first running var-lib-nfs-rpc_pipefs.mount, which will load
> sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
> don't see what ensures anything happening before gssproxy runs.
It happens during the mount on the client and when the server
is started. 

> 
> We want to make sure your testing's not just getting lucky on the
> startup order.
The reason it working is because rpc.gssd is being started on the server 
these days for callbacks and the After= line in rpc-svcgssd.service is being 
executed before the ConditionPathExists which cause rpc.svcgssd not to start.

So when gssproxy.service does it's "Before=nfs-secure.service nfs-secure-server.service"
line everything is loaded before gssproxy start... 

I'm think gssproxy.service just needs to the put the Wants and After=
var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 

> 
>> Plus, from my understanding...  loading module from a service 
>> file is a big no no! People were having problems with
>> way back when... 
> 
> Any pointers?  Google's not finding me anything.
Search the the Fedora bz's when systemd first came out... 
There were a number of "colorful" discussion on how things
were so broken until systemd came along and saved humanity!  ;-) 

steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 22, 2014, 9:32 p.m. UTC | #10

On Mon, 22 Sep 2014 17:14:05 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> > On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>
> >>
> >> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>> Steve Dickson <[e-mail]> 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.
> >>>>
> >>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>> ---
> >>>>  systemd/nfs-server.service | 5 +++--
> >>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/systemd/nfs-server.service
> >>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
> >>>> --- a/systemd/nfs-server.service
> >>>> +++ b/systemd/nfs-server.service
> >>>> @@ -2,12 +2,13 @@
> >>>>  Description=NFS server and services
> >>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>  Requires= nfs-mountd.service
> >>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> >>>> +Wants=rpc-gssd.service  
> >>>>  Wants=rpc-statd-notify.service
> >>>>  
> >>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> >>>> -After= rpc-gssd.service rpc-svcgssd.service
> >>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >>>>  Before= rpc-statd-notify.service
> >>>>  
> >>>>  Wants=nfs-config.service
> >>>
> >>> I think you really need to insure that the modules are loaded
> >>> before any of the server services are started, perhaps adding a
> >>> unit file that exec's modprobe and has "Before: gssproxy.service
> >>>  " in it ?
> >> I really don't think its needed... From my testing it appears 
> >> gssproxy is always being started and rpc.svcgssd is not... 
> > 
> > Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as
> > both "Requires=" and "After=", so rpc-svcgssd.service will never run
> > without first running var-lib-nfs-rpc_pipefs.mount, which will load
> > sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
> > don't see what ensures anything happening before gssproxy runs.
> It happens during the mount on the client and when the server
> is started. 
> 
> > 
> > We want to make sure your testing's not just getting lucky on the
> > startup order.
> The reason it working is because rpc.gssd is being started on the
> server these days for callbacks and the After= line in
> rpc-svcgssd.service is being executed before the ConditionPathExists
> which cause rpc.svcgssd not to start.

This guarantees ordering (to some degree) between rpc.gssd and
rpoc.svcgssd, but says nothing about gssproxy ...

> So when gssproxy.service does it's "Before=nfs-secure.service
> nfs-secure-server.service" line everything is loaded before gssproxy
> start... 
> 
> I'm think gssproxy.service just needs to the put the Wants and After=
> var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 

Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention of
nfs services in gssproxy unit file so you have complete control of the
dependencies ?

> > 
> >> Plus, from my understanding...  loading module from a service 
> >> file is a big no no! People were having problems with
> >> way back when... 
> > 
> > Any pointers?  Google's not finding me anything.
> Search the the Fedora bz's when systemd first came out... 
> There were a number of "colorful" discussion on how things
> were so broken until systemd came along and saved humanity!  ;-) 

This doesn't help really, I see no reason why we could not have a pre
exec statement to modprobe rpc_authgss in a unit file (whether that is
var-lib-nfs-rpc_pipefs.mount or something else), to guarantee correct
ordering.

Simo.

J. Bruce Fields Sept. 22, 2014, 10:34 p.m. UTC | #11

On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote:
> 
> 
> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> > On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>
> >>
> >> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>> Steve Dickson <[e-mail]> 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.
> >>>>
> >>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>> ---
> >>>>  systemd/nfs-server.service | 5 +++--
> >>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> >>>> index 2fa7387..c740fa2 100644
> >>>> --- a/systemd/nfs-server.service
> >>>> +++ b/systemd/nfs-server.service
> >>>> @@ -2,12 +2,13 @@
> >>>>  Description=NFS server and services
> >>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>  Requires= nfs-mountd.service
> >>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> >>>> +Wants=rpc-gssd.service  
> >>>>  Wants=rpc-statd-notify.service
> >>>>  
> >>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> >>>> -After= rpc-gssd.service rpc-svcgssd.service
> >>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >>>>  Before= rpc-statd-notify.service
> >>>>  
> >>>>  Wants=nfs-config.service
> >>>
> >>> I think you really need to insure that the modules are loaded before
> >>> any of the server services are started, perhaps adding a unit file that
> >>> exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
> >>> in it ?
> >> I really don't think its needed... From my testing it appears 
> >> gssproxy is always being started and rpc.svcgssd is not... 
> > 
> > Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as both
> > "Requires=" and "After=", so rpc-svcgssd.service will never run
> > without first running var-lib-nfs-rpc_pipefs.mount, which will load
> > sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
> > don't see what ensures anything happening before gssproxy runs.
> It happens during the mount on the client and when the server
> is started. 
> 
> > 
> > We want to make sure your testing's not just getting lucky on the
> > startup order.
> The reason it working is because rpc.gssd is being started on the server 
> these days for callbacks and the After= line in rpc-svcgssd.service is being 
> executed before the ConditionPathExists which cause rpc.svcgssd not to start.

nfs-utils$ grep After systemd/rpc-svcgssd.service 
After=var-lib-nfs-rpc_pipefs.mount
After=gssproxy.service
After=nfs-config.service

There doesn't seem to be an After= line referring to rpc.gssd.

> So when gssproxy.service does it's "Before=nfs-secure.service nfs-secure-server.service"
> line everything is loaded before gssproxy start... 

That line only makes gss-proxy start before those other things.

> I'm think gssproxy.service just needs to the put the Wants and After=
> var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 

That would make sure sunrpc's loaded, but not auth_rpcgss.

> >> Plus, from my understanding...  loading module from a service 
> >> file is a big no no! People were having problems with
> >> way back when... 
> > 
> > Any pointers?  Google's not finding me anything.
> Search the the Fedora bz's when systemd first came out... 

All I can find is:

	https://bugzilla.redhat.com/show_bug.cgi?id=699040#c16

	Btw afaik modules should be loaded via autoloading based on bus
	information, or via /etc/modules-load.d/*.conf. and unloading a
	module from the kernel should not be done except for debugging
	purposes so loading all these modules is it really necessary?

Which I agree with--modules should normally load on demand when we need
them, and we should have an explanation for exceptions.

But here we have a pretty reasonable explanation (we need to know
on startup whether a certain module has a certain feature, and we have
to modprobe to do that).  I don't see any blanket prohibition against
loading modules.

OK, and in 702707 there's a request for support of the monolithic kernel
case, but that's easy, we just allow the modprobe to fail in that case.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steve Dickson Sept. 22, 2014, 10:57 p.m. UTC | #12

On 09/22/2014 05:32 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 17:14:05 -0400
> Steve Dickson <[e-mail]> wrote:
> 
>>
>>
>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
>>>>
>>>>
>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
>>>>> Steve Dickson <[e-mail]> 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.
>>>>>>
>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
>>>>>> ---
>>>>>>  systemd/nfs-server.service | 5 +++--
>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/systemd/nfs-server.service
>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
>>>>>> --- a/systemd/nfs-server.service
>>>>>> +++ b/systemd/nfs-server.service
>>>>>> @@ -2,12 +2,13 @@
>>>>>>  Description=NFS server and services
>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>  Requires= nfs-mountd.service
>>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>>>>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
>>>>>> +Wants=rpc-gssd.service  
>>>>>>  Wants=rpc-statd-notify.service
>>>>>>  
>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
>>>>>> -After= rpc-gssd.service rpc-svcgssd.service
>>>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>>>>>>  Before= rpc-statd-notify.service
>>>>>>  
>>>>>>  Wants=nfs-config.service
>>>>>
>>>>> I think you really need to insure that the modules are loaded
>>>>> before any of the server services are started, perhaps adding a
>>>>> unit file that exec's modprobe and has "Before: gssproxy.service
>>>>>  " in it ?
>>>> I really don't think its needed... From my testing it appears 
>>>> gssproxy is always being started and rpc.svcgssd is not... 
>>>
>>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as
>>> both "Requires=" and "After=", so rpc-svcgssd.service will never run
>>> without first running var-lib-nfs-rpc_pipefs.mount, which will load
>>> sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
>>> don't see what ensures anything happening before gssproxy runs.
>> It happens during the mount on the client and when the server
>> is started. 
>>
>>>
>>> We want to make sure your testing's not just getting lucky on the
>>> startup order.
>> The reason it working is because rpc.gssd is being started on the
>> server these days for callbacks and the After= line in
>> rpc-svcgssd.service is being executed before the ConditionPathExists
>> which cause rpc.svcgssd not to start.
> 
> This guarantees ordering (to some degree) between rpc.gssd and
> rpoc.svcgssd, but says nothing about gssproxy ...
The question was how is the auth_rpcgss module being loaded. Since
both rpc-svcgssd.service and rpc-gssd.service service have
a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
them, that's how auth_rpcgss is being loaded. 

If you only in enable gssproxy (not nfs-server or nfs-client) the 
module still get loaded via gssproxy,service file 

>> So when gssproxy.service does it's "Before=nfs-secure.service
>> nfs-secure-server.service" line everything is loaded before gssproxy
>> start... 
>>
>> I'm think gssproxy.service just needs to the put the Wants and After=
>> var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 
> 
> Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
> to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention of
> nfs services in gssproxy unit file so you have complete control of the
> dependencies ?
No. 
The loading of sunrpc and the mounting of the file system has nothing to
do with starting up the gssd daemons.

I would suggest gssproxy does to two things:

1) Add a Requires: nfs-utils to the spec file since you are requiring 
   services from  nfs-utils

2) Add a After=var-lib-nfs-rpc_pipefs.mount to the gssproxy.service 
   file since gssproxy could careless about either rpc.gssd or rpc.svcgssd
   daemons. All it is looking for is the sunrpc and auth_rpcgss kernel
   modules.

steved.

> 
>>>
>>>> Plus, from my understanding...  loading module from a service 
>>>> file is a big no no! People were having problems with
>>>> way back when... 
>>>
>>> Any pointers?  Google's not finding me anything.
>> Search the the Fedora bz's when systemd first came out... 
>> There were a number of "colorful" discussion on how things
>> were so broken until systemd came along and saved humanity!  ;-) 
> 
> This doesn't help really, I see no reason why we could not have a pre
> exec statement to modprobe rpc_authgss in a unit file (whether that is
> var-lib-nfs-rpc_pipefs.mount or something else), to guarantee correct
> ordering.
> 
> Simo.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Steve Dickson Sept. 22, 2014, 11:58 p.m. UTC | #13

On 09/22/2014 06:34 PM, J. Bruce Fields wrote:
> On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote:
>>
>>
>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
>>>>
>>>>
>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
>>>>> Steve Dickson <[e-mail]> 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.
>>>>>>
>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
>>>>>> ---
>>>>>>  systemd/nfs-server.service | 5 +++--
>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
>>>>>> index 2fa7387..c740fa2 100644
>>>>>> --- a/systemd/nfs-server.service
>>>>>> +++ b/systemd/nfs-server.service
>>>>>> @@ -2,12 +2,13 @@
>>>>>>  Description=NFS server and services
>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>  Requires= nfs-mountd.service
>>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>>>>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
>>>>>> +Wants=rpc-gssd.service  
>>>>>>  Wants=rpc-statd-notify.service
>>>>>>  
>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
>>>>>> -After= rpc-gssd.service rpc-svcgssd.service
>>>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>>>>>>  Before= rpc-statd-notify.service
>>>>>>  
>>>>>>  Wants=nfs-config.service
>>>>>
>>>>> I think you really need to insure that the modules are loaded before
>>>>> any of the server services are started, perhaps adding a unit file that
>>>>> exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
>>>>> in it ?
>>>> I really don't think its needed... From my testing it appears 
>>>> gssproxy is always being started and rpc.svcgssd is not... 
>>>
>>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as both
>>> "Requires=" and "After=", so rpc-svcgssd.service will never run
>>> without first running var-lib-nfs-rpc_pipefs.mount, which will load
>>> sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
>>> don't see what ensures anything happening before gssproxy runs.
>> It happens during the mount on the client and when the server
>> is started. 
>>
>>>
>>> We want to make sure your testing's not just getting lucky on the
>>> startup order.
>> The reason it working is because rpc.gssd is being started on the server 
>> these days for callbacks and the After= line in rpc-svcgssd.service is being 
>> executed before the ConditionPathExists which cause rpc.svcgssd not to start.
> 
> nfs-utils$ grep After systemd/rpc-svcgssd.service 
> After=var-lib-nfs-rpc_pipefs.mount
> After=gssproxy.service
> After=nfs-config.service
> 
> There doesn't seem to be an After= line referring to rpc.gssd.
No, why should there be? There is After= line referring to rpc.gssd
in nfs-server.service

grep After systemd/nfs-server.service 
After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
After= nfs-idmapd.service rpc-statd.service
After= rpc-gssd.service rpc-svcgssd.service
After=nfs-config.service

So when the server starts,rpc.gssd will start and rpc.svcgssd will start
if gssproxy is not enable and there is a key tab. 

> 
>> So when gssproxy.service does it's "Before=nfs-secure.service nfs-secure-server.service"
>> line everything is loaded before gssproxy start... 
> 
> That line only makes gss-proxy start before those other things.
Right, which will load the sunrpc modules.

> 
>> I'm think gssproxy.service just needs to the put the Wants and After=
>> var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 
> 
> That would make sure sunrpc's loaded, but not auth_rpcgss.
On the client side the mount -o sec=krb5? loads auth_rpcgss module.
Maybe the loading of nfsd loads the module? But I don't think that
module has to be loaded for any of the gss daemons (gssd, svcgssd or
gssproxy) to start successfully...

 
> 
>>>> Plus, from my understanding...  loading module from a service 
>>>> file is a big no no! People were having problems with
>>>> way back when... 
>>>
>>> Any pointers?  Google's not finding me anything.
>> Search the the Fedora bz's when systemd first came out... 
> 
> All I can find is:
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=699040#c16
> 
> 	Btw afaik modules should be loaded via autoloading based on bus
> 	information, or via /etc/modules-load.d/*.conf. and unloading a
> 	module from the kernel should not be done except for debugging
> 	purposes so loading all these modules is it really necessary?
> 
> Which I agree with--modules should normally load on demand when we need
> them, and we should have an explanation for exceptions.
Yes, this was the conversation I was referring to.. Thank you 
for digging it out.. 

> 
> But here we have a pretty reasonable explanation (we need to know
> on startup whether a certain module has a certain feature, and we have
> to modprobe to do that).  I don't see any blanket prohibition against
> loading modules.
Lets talk with the systemd people to see what they say...

steved.

> 
> OK, and in 702707 there's a request for support of the monolithic kernel
> case, but that's easy, we just allow the modprobe to fail in that case.
> 
> --b.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 23, 2014, 12:19 a.m. UTC | #14

On Mon, 22 Sep 2014 18:57:10 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/22/2014 05:32 PM, Simo Sorce wrote:
> > On Mon, 22 Sep 2014 17:14:05 -0400
> > Steve Dickson <[e-mail]> wrote:
> > 
> >>
> >>
> >> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> >>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>>>
> >>>>
> >>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>>>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>>>> Steve Dickson <[e-mail]> 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.
> >>>>>>
> >>>>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>>>> ---
> >>>>>>  systemd/nfs-server.service | 5 +++--
> >>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/systemd/nfs-server.service
> >>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
> >>>>>> --- a/systemd/nfs-server.service
> >>>>>> +++ b/systemd/nfs-server.service
> >>>>>> @@ -2,12 +2,13 @@
> >>>>>>  Description=NFS server and services
> >>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>  Requires= nfs-mountd.service
> >>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >>>>>> rpc-svcgssd.service +Wants=rpc-statd.service
> >>>>>> nfs-idmapd.service +Wants=rpc-gssd.service  
> >>>>>>  Wants=rpc-statd-notify.service
> >>>>>>  
> >>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> >>>>>> -After= rpc-gssd.service rpc-svcgssd.service
> >>>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >>>>>>  Before= rpc-statd-notify.service
> >>>>>>  
> >>>>>>  Wants=nfs-config.service
> >>>>>
> >>>>> I think you really need to insure that the modules are loaded
> >>>>> before any of the server services are started, perhaps adding a
> >>>>> unit file that exec's modprobe and has "Before: gssproxy.service
> >>>>>  " in it ?
> >>>> I really don't think its needed... From my testing it appears 
> >>>> gssproxy is always being started and rpc.svcgssd is not... 
> >>>
> >>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as
> >>> both "Requires=" and "After=", so rpc-svcgssd.service will never
> >>> run without first running var-lib-nfs-rpc_pipefs.mount, which
> >>> will load sunrpc.  But I don't see where auth_rpcgss is getting
> >>> loaded.  And I don't see what ensures anything happening before
> >>> gssproxy runs.
> >> It happens during the mount on the client and when the server
> >> is started. 
> >>
> >>>
> >>> We want to make sure your testing's not just getting lucky on the
> >>> startup order.
> >> The reason it working is because rpc.gssd is being started on the
> >> server these days for callbacks and the After= line in
> >> rpc-svcgssd.service is being executed before the
> >> ConditionPathExists which cause rpc.svcgssd not to start.
> > 
> > This guarantees ordering (to some degree) between rpc.gssd and
> > rpoc.svcgssd, but says nothing about gssproxy ...
> The question was how is the auth_rpcgss module being loaded. Since
> both rpc-svcgssd.service and rpc-gssd.service service have
> a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
> them, that's how auth_rpcgss is being loaded. 
> 
> If you only in enable gssproxy (not nfs-server or nfs-client) the 
> module still get loaded via gssproxy,service file 
> 
> >> So when gssproxy.service does it's "Before=nfs-secure.service
> >> nfs-secure-server.service" line everything is loaded before
> >> gssproxy start... 
> >>
> >> I'm think gssproxy.service just needs to the put the Wants and
> >> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that Before
> >> line.. 
> > 
> > Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
> > to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention
> > of nfs services in gssproxy unit file so you have complete control
> > of the dependencies ?
> No. 
> The loading of sunrpc and the mounting of the file system has nothing
> to do with starting up the gssd daemons.
> 
> I would suggest gssproxy does to two things:
> 
> 1) Add a Requires: nfs-utils to the spec file since you are requiring 
>    services from  nfs-utils

No we are not requiring services from nfs-utils, nfs-utils is one of
our users, you got that reversed.

> 2) Add a After=var-lib-nfs-rpc_pipefs.mount to the gssproxy.service 
>    file since gssproxy could careless about either rpc.gssd or
> rpc.svcgssd daemons. All it is looking for is the sunrpc and
> auth_rpcgss kernel modules.

The correct thing is to add a Before: gssproxy.service to
var-lib-nfs-rpc_pipefs.mount IMO.

Simo.

Simo Sorce Sept. 23, 2014, 12:26 a.m. UTC | #15

On Mon, 22 Sep 2014 19:58:05 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/22/2014 06:34 PM, J. Bruce Fields wrote:
> > On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote:
> >>
> >>
> >> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> >>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>>>
> >>>>
> >>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>>>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>>>> Steve Dickson <[e-mail]> 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.
> >>>>>>
> >>>>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>>>> ---
> >>>>>>  systemd/nfs-server.service | 5 +++--
> >>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>>
> >>>>>> diff --git a/systemd/nfs-server.service
> >>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
> >>>>>> --- a/systemd/nfs-server.service
> >>>>>> +++ b/systemd/nfs-server.service
> >>>>>> @@ -2,12 +2,13 @@
> >>>>>>  Description=NFS server and services
> >>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>  Requires= nfs-mountd.service
> >>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >>>>>> rpc-svcgssd.service +Wants=rpc-statd.service
> >>>>>> nfs-idmapd.service +Wants=rpc-gssd.service  
> >>>>>>  Wants=rpc-statd-notify.service
> >>>>>>  
> >>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> >>>>>> -After= rpc-gssd.service rpc-svcgssd.service
> >>>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> >>>>>>  Before= rpc-statd-notify.service
> >>>>>>  
> >>>>>>  Wants=nfs-config.service
> >>>>>
> >>>>> I think you really need to insure that the modules are loaded
> >>>>> before any of the server services are started, perhaps adding a
> >>>>> unit file that exec's modprobe and has "Before:
> >>>>> gssproxy.service rpc-svcgssd.service" in it ?
> >>>> I really don't think its needed... From my testing it appears 
> >>>> gssproxy is always being started and rpc.svcgssd is not... 
> >>>
> >>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount
> >>> as both "Requires=" and "After=", so rpc-svcgssd.service will
> >>> never run without first running var-lib-nfs-rpc_pipefs.mount,
> >>> which will load sunrpc.  But I don't see where auth_rpcgss is
> >>> getting loaded.  And I don't see what ensures anything happening
> >>> before gssproxy runs.
> >> It happens during the mount on the client and when the server
> >> is started. 
> >>
> >>>
> >>> We want to make sure your testing's not just getting lucky on the
> >>> startup order.
> >> The reason it working is because rpc.gssd is being started on the
> >> server these days for callbacks and the After= line in
> >> rpc-svcgssd.service is being executed before the
> >> ConditionPathExists which cause rpc.svcgssd not to start.
> > 
> > nfs-utils$ grep After systemd/rpc-svcgssd.service 
> > After=var-lib-nfs-rpc_pipefs.mount
> > After=gssproxy.service
> > After=nfs-config.service
> > 
> > There doesn't seem to be an After= line referring to rpc.gssd.
> No, why should there be? There is After= line referring to rpc.gssd
> in nfs-server.service
> 
> grep After systemd/nfs-server.service 
> After= network.target proc-fs-nfsd.mount rpcbind.target
> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> After= rpc-gssd.service rpc-svcgssd.service
> After=nfs-config.service
> 
> So when the server starts,rpc.gssd will start and rpc.svcgssd will
> start if gssproxy is not enable and there is a key tab. 

They can start in parallel, there is nothing in that line that makes
one start before the other.

If you are relying on this you are relying on luck.

> >> So when gssproxy.service does it's "Before=nfs-secure.service
> >> nfs-secure-server.service" line everything is loaded before
> >> gssproxy start... 
> > 
> > That line only makes gss-proxy start before those other things.
> Right, which will load the sunrpc modules.

No, starting before those service in itself achieves nothing.\
I think what may cause the module to load maybe the fact
gssproxy.service includes:
Requires=proc-fs-nfsd.mount

But to be honest this was a hack to deal with broken nfs service files,
gss-proxy should not require nfsd, the dependency should be the other
way around, as gss-proxy can run on machines where there is no nfs
service whatsoever, as it stand this is a bug in gssproxy.service and
I'd like to fix it.

> >> I'm think gssproxy.service just needs to the put the Wants and
> >> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that Before
> >> line.. 
> > 
> > That would make sure sunrpc's loaded, but not auth_rpcgss.
> On the client side the mount -o sec=krb5? loads auth_rpcgss module.

This happens eons after gss-proxy has been started.

> Maybe the loading of nfsd loads the module? But I don't think that
> module has to be loaded for any of the gss daemons (gssd, svcgssd or
> gssproxy) to start successfully...

Atm it *has to*.
If the module is not loaded then /proc/net/rpc/use-gss-proxy will not
exist and GSS-Proxy will not register with the kernel (it does so only
at startup). It also means rpc.svcgssd will be started when it shouldn't

 
> >>>> Plus, from my understanding...  loading module from a service 
> >>>> file is a big no no! People were having problems with
> >>>> way back when... 
> >>>
> >>> Any pointers?  Google's not finding me anything.
> >> Search the the Fedora bz's when systemd first came out... 
> > 
> > All I can find is:
> > 
> > 	https://bugzilla.redhat.com/show_bug.cgi?id=699040#c16
> > 
> > 	Btw afaik modules should be loaded via autoloading based on
> > bus information, or via /etc/modules-load.d/*.conf. and unloading a
> > 	module from the kernel should not be done except for
> > debugging purposes so loading all these modules is it really
> > necessary?
> > 
> > Which I agree with--modules should normally load on demand when we
> > need them, and we should have an explanation for exceptions.
> Yes, this was the conversation I was referring to.. Thank you 
> for digging it out.. 
> 
> > 
> > But here we have a pretty reasonable explanation (we need to know
> > on startup whether a certain module has a certain feature, and we
> > have to modprobe to do that).  I don't see any blanket prohibition
> > against loading modules.
> Lets talk with the systemd people to see what they say...

Feel free to CC the,.

Simo.

Steve Dickson Sept. 23, 2014, 1:19 a.m. UTC | #16

On 09/22/2014 08:19 PM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 18:57:10 -0400
> Steve Dickson <[e-mail]> wrote:
> 
>>
>>
>> On 09/22/2014 05:32 PM, Simo Sorce wrote:
>>> On Mon, 22 Sep 2014 17:14:05 -0400
>>> Steve Dickson <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
>>>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
>>>>>>
>>>>>>
>>>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
>>>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
>>>>>>> Steve Dickson <[e-mail]> 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.
>>>>>>>>
>>>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
>>>>>>>> ---
>>>>>>>>  systemd/nfs-server.service | 5 +++--
>>>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>> diff --git a/systemd/nfs-server.service
>>>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
>>>>>>>> --- a/systemd/nfs-server.service
>>>>>>>> +++ b/systemd/nfs-server.service
>>>>>>>> @@ -2,12 +2,13 @@
>>>>>>>>  Description=NFS server and services
>>>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>>>  Requires= nfs-mountd.service
>>>>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>>>>>>>> rpc-svcgssd.service +Wants=rpc-statd.service
>>>>>>>> nfs-idmapd.service +Wants=rpc-gssd.service  
>>>>>>>>  Wants=rpc-statd-notify.service
>>>>>>>>  
>>>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
>>>>>>>> -After= rpc-gssd.service rpc-svcgssd.service
>>>>>>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
>>>>>>>>  Before= rpc-statd-notify.service
>>>>>>>>  
>>>>>>>>  Wants=nfs-config.service
>>>>>>>
>>>>>>> I think you really need to insure that the modules are loaded
>>>>>>> before any of the server services are started, perhaps adding a
>>>>>>> unit file that exec's modprobe and has "Before: gssproxy.service
>>>>>>>  " in it ?
>>>>>> I really don't think its needed... From my testing it appears 
>>>>>> gssproxy is always being started and rpc.svcgssd is not... 
>>>>>
>>>>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as
>>>>> both "Requires=" and "After=", so rpc-svcgssd.service will never
>>>>> run without first running var-lib-nfs-rpc_pipefs.mount, which
>>>>> will load sunrpc.  But I don't see where auth_rpcgss is getting
>>>>> loaded.  And I don't see what ensures anything happening before
>>>>> gssproxy runs.
>>>> It happens during the mount on the client and when the server
>>>> is started. 
>>>>
>>>>>
>>>>> We want to make sure your testing's not just getting lucky on the
>>>>> startup order.
>>>> The reason it working is because rpc.gssd is being started on the
>>>> server these days for callbacks and the After= line in
>>>> rpc-svcgssd.service is being executed before the
>>>> ConditionPathExists which cause rpc.svcgssd not to start.
>>>
>>> This guarantees ordering (to some degree) between rpc.gssd and
>>> rpoc.svcgssd, but says nothing about gssproxy ...
>> The question was how is the auth_rpcgss module being loaded. Since
>> both rpc-svcgssd.service and rpc-gssd.service service have
>> a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
>> them, that's how auth_rpcgss is being loaded. 
>>
>> If you only in enable gssproxy (not nfs-server or nfs-client) the 
>> module still get loaded via gssproxy,service file 
>>
>>>> So when gssproxy.service does it's "Before=nfs-secure.service
>>>> nfs-secure-server.service" line everything is loaded before
>>>> gssproxy start... 
>>>>
>>>> I'm think gssproxy.service just needs to the put the Wants and
>>>> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that Before
>>>> line.. 
>>>
>>> Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
>>> to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention
>>> of nfs services in gssproxy unit file so you have complete control
>>> of the dependencies ?
>> No. 
>> The loading of sunrpc and the mounting of the file system has nothing
>> to do with starting up the gssd daemons.
>>
>> I would suggest gssproxy does to two things:
>>
>> 1) Add a Requires: nfs-utils to the spec file since you are requiring 
>>    services from  nfs-utils
> 
> No we are not requiring services from nfs-utils, nfs-utils is one of
> our users, you got that reversed.
So having "Before=nfs-secure.service nfs-secure-server.service" in 
gssproxy.service and not having nfs-utils installed will not cause the
service fail during start up? 

> 
>> 2) Add a After=var-lib-nfs-rpc_pipefs.mount to the gssproxy.service 
>>    file since gssproxy could careless about either rpc.gssd or
>> rpc.svcgssd daemons. All it is looking for is the sunrpc and
>> auth_rpcgss kernel modules.
> 
> The correct thing is to add a Before: gssproxy.service to
> var-lib-nfs-rpc_pipefs.mount IMO.
Again what happen if gssproxy is not installed? Things will 
still come up successfully?

steved

> 
> Simo.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Sept. 23, 2014, 1:42 a.m. UTC | #17

On Mon, 22 Sep 2014 16:00:50 -0400 Simo Sorce <[e-mail]> wrote:

> On Mon, 22 Sep 2014 15:53:46 -0400
> Steve Dickson <[e-mail]> wrote:
> 
> > 
> > 
> > On 09/22/2014 03:46 PM, Simo Sorce wrote:
> > > On Mon, 22 Sep 2014 15:40:57 -0400
> > > "J. Bruce Fields" <[e-mail]> 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

NeilBrown Sept. 23, 2014, 2:01 a.m. UTC | #18

On Mon, 22 Sep 2014 18:34:23 -0400 "J. Bruce Fields" <[e-mail]>
wrote:

> On Mon, Sep 22, 2014 at 05:14:05PM -0400, Steve Dickson wrote:
> > 
> > 
> > On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> > > On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> > >>
> > >>
> > >> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> > >>> On Mon, 22 Sep 2014 15:20:07 -0400
> > >>> Steve Dickson <[e-mail]> 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.
> > >>>>
> > >>>> Signed-off-by: Steve Dickson <[e-mail]>
> > >>>> ---
> > >>>>  systemd/nfs-server.service | 5 +++--
> > >>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> > >>>>
> > >>>> diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
> > >>>> index 2fa7387..c740fa2 100644
> > >>>> --- a/systemd/nfs-server.service
> > >>>> +++ b/systemd/nfs-server.service
> > >>>> @@ -2,12 +2,13 @@
> > >>>>  Description=NFS server and services
> > >>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> > >>>>  Requires= nfs-mountd.service
> > >>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> > >>>> rpc-svcgssd.service +Wants=rpc-statd.service nfs-idmapd.service 
> > >>>> +Wants=rpc-gssd.service  
> > >>>>  Wants=rpc-statd-notify.service
> > >>>>  
> > >>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> > >>>> nfs-mountd.service After= nfs-idmapd.service rpc-statd.service
> > >>>> -After= rpc-gssd.service rpc-svcgssd.service
> > >>>> +After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
> > >>>>  Before= rpc-statd-notify.service
> > >>>>  
> > >>>>  Wants=nfs-config.service
> > >>>
> > >>> I think you really need to insure that the modules are loaded before
> > >>> any of the server services are started, perhaps adding a unit file that
> > >>> exec's modprobe and has "Before: gssproxy.service rpc-svcgssd.service"
> > >>> in it ?
> > >> I really don't think its needed... From my testing it appears 
> > >> gssproxy is always being started and rpc.svcgssd is not... 
> > > 
> > > Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount as both
> > > "Requires=" and "After=", so rpc-svcgssd.service will never run
> > > without first running var-lib-nfs-rpc_pipefs.mount, which will load
> > > sunrpc.  But I don't see where auth_rpcgss is getting loaded.  And I
> > > don't see what ensures anything happening before gssproxy runs.
> > It happens during the mount on the client and when the server
> > is started. 
> > 
> > > 
> > > We want to make sure your testing's not just getting lucky on the
> > > startup order.
> > The reason it working is because rpc.gssd is being started on the server 
> > these days for callbacks and the After= line in rpc-svcgssd.service is being 
> > executed before the ConditionPathExists which cause rpc.svcgssd not to start.
> 
> nfs-utils$ grep After systemd/rpc-svcgssd.service 
> After=var-lib-nfs-rpc_pipefs.mount
> After=gssproxy.service
> After=nfs-config.service
> 
> There doesn't seem to be an After= line referring to rpc.gssd.
> 
> > So when gssproxy.service does it's "Before=nfs-secure.service nfs-secure-server.service"
> > line everything is loaded before gssproxy start... 
> 
> That line only makes gss-proxy start before those other things.
> 
> > I'm think gssproxy.service just needs to the put the Wants and After=
> > var-lib-nfs-rpc_pipefs.mount lines, instead of that Before line.. 
> 
> That would make sure sunrpc's loaded, but not auth_rpcgss.
> 
> > >> Plus, from my understanding...  loading module from a service 
> > >> file is a big no no! People were having problems with
> > >> way back when... 
> > > 
> > > Any pointers?  Google's not finding me anything.
> > Search the the Fedora bz's when systemd first came out... 
> 
> All I can find is:
> 
> 	https://bugzilla.redhat.com/show_bug.cgi?id=699040#c16
> 
> 	Btw afaik modules should be loaded via autoloading based on bus
> 	information, or via /etc/modules-load.d/*.conf. and unloading a
> 	module from the kernel should not be done except for debugging
> 	purposes so loading all these modules is it really necessary?
> 
> Which I agree with--modules should normally load on demand when we need
> them, and we should have an explanation for exceptions.
> 
> But here we have a pretty reasonable explanation (we need to know
> on startup whether a certain module has a certain feature, and we have
> to modprobe to do that).  I don't see any blanket prohibition against
> loading modules.
> 
> OK, and in 702707 there's a request for support of the monolithic kernel
> case, but that's easy, we just allow the modprobe to fail in that case.
> 

I certainly think it is absolutely fine for the service files for the gss
daemons to modprobe auth_rpcgss.  It would be really nice if the loading of
the module would automatically trigger the starting of the daemons, or would
signal the daemons to start talking to the module.  But that is probably
unnecessary complexity.

I would probably have a separate service file which did the modprobe.
It would declare itself to be Before= all of the gss daemons,
and it would be conditional on /etc/krb5.conf existing.
nfs-server would Want it, so it would be started when needed at just the
right time...

NeilBrown

J. Bruce Fields Sept. 23, 2014, 2:09 a.m. UTC | #19

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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

NeilBrown Sept. 23, 2014, 2:55 a.m. UTC | #20

On Mon, 22 Sep 2014 22:09:28 -0400 "J. Bruce Fields" <[e-mail]>
wrote:

> 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.

Having to fix up unit files is something I would much rather avoid.  I think
of them as code and just because they can be edited it doesn't mean they
should be.

I'm quite open to having rpc.svcgssd test to see if gssproxy is installed
rather than if it is running.  In that case we would have a 'Want=' somewhere
in nfs-utils for gssproxy.service (which I previously said I didn't like but
I'm beginning to see the wisdom of).

But if gssproxy isn't installed, then I think rpc.svcgssd should run whether
use-gss-proxy is present or not.

> 
> 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."

This is quite a strong argument.

Thanks,
NeilBrown

> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [e-mail]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 23, 2014, 12:45 p.m. UTC | #21

On Tue, 23 Sep 2014 11:42:29 +1000
NeilBrown <[e-mail]> wrote:

> On Mon, 22 Sep 2014 16:00:50 -0400 Simo Sorce <[e-mail]> wrote:
> 
> > On Mon, 22 Sep 2014 15:53:46 -0400
> > Steve Dickson <[e-mail]> wrote:
> > 
> > > 
> > > 
> > > On 09/22/2014 03:46 PM, Simo Sorce wrote:
> > > > On Mon, 22 Sep 2014 15:40:57 -0400
> > > > "J. Bruce Fields" <[e-mail]> 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 Sept. 23, 2014, 12:52 p.m. UTC | #22

On Mon, 22 Sep 2014 21:19:18 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/22/2014 08:19 PM, Simo Sorce wrote:
> > On Mon, 22 Sep 2014 18:57:10 -0400
> > Steve Dickson <[e-mail]> wrote:
> > 
> >>
> >>
> >> On 09/22/2014 05:32 PM, Simo Sorce wrote:
> >>> On Mon, 22 Sep 2014 17:14:05 -0400
> >>> Steve Dickson <[e-mail]> wrote:
> >>>
> >>>>
> >>>>
> >>>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> >>>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>>>>>> Steve Dickson <[e-mail]> 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.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>>>>>> ---
> >>>>>>>>  systemd/nfs-server.service | 5 +++--
> >>>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>>>>
> >>>>>>>> diff --git a/systemd/nfs-server.service
> >>>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
> >>>>>>>> --- a/systemd/nfs-server.service
> >>>>>>>> +++ b/systemd/nfs-server.service
> >>>>>>>> @@ -2,12 +2,13 @@
> >>>>>>>>  Description=NFS server and services
> >>>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>>>  Requires= nfs-mountd.service
> >>>>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
> >>>>>>>> rpc-svcgssd.service +Wants=rpc-statd.service
> >>>>>>>> nfs-idmapd.service +Wants=rpc-gssd.service  
> >>>>>>>>  Wants=rpc-statd-notify.service
> >>>>>>>>  
> >>>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>>> nfs-mountd.service After= nfs-idmapd.service
> >>>>>>>> rpc-statd.service -After= rpc-gssd.service
> >>>>>>>> rpc-svcgssd.service +After= rpc-gssd.service
> >>>>>>>> gssproxy.service rpc-svcgssd.service Before=
> >>>>>>>> rpc-statd-notify.service 
> >>>>>>>>  Wants=nfs-config.service
> >>>>>>>
> >>>>>>> I think you really need to insure that the modules are loaded
> >>>>>>> before any of the server services are started, perhaps adding
> >>>>>>> a unit file that exec's modprobe and has "Before:
> >>>>>>> gssproxy.service " in it ?
> >>>>>> I really don't think its needed... From my testing it appears 
> >>>>>> gssproxy is always being started and rpc.svcgssd is not... 
> >>>>>
> >>>>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount
> >>>>> as both "Requires=" and "After=", so rpc-svcgssd.service will
> >>>>> never run without first running var-lib-nfs-rpc_pipefs.mount,
> >>>>> which will load sunrpc.  But I don't see where auth_rpcgss is
> >>>>> getting loaded.  And I don't see what ensures anything
> >>>>> happening before gssproxy runs.
> >>>> It happens during the mount on the client and when the server
> >>>> is started. 
> >>>>
> >>>>>
> >>>>> We want to make sure your testing's not just getting lucky on
> >>>>> the startup order.
> >>>> The reason it working is because rpc.gssd is being started on the
> >>>> server these days for callbacks and the After= line in
> >>>> rpc-svcgssd.service is being executed before the
> >>>> ConditionPathExists which cause rpc.svcgssd not to start.
> >>>
> >>> This guarantees ordering (to some degree) between rpc.gssd and
> >>> rpoc.svcgssd, but says nothing about gssproxy ...
> >> The question was how is the auth_rpcgss module being loaded. Since
> >> both rpc-svcgssd.service and rpc-gssd.service service have
> >> a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
> >> them, that's how auth_rpcgss is being loaded. 
> >>
> >> If you only in enable gssproxy (not nfs-server or nfs-client) the 
> >> module still get loaded via gssproxy,service file 
> >>
> >>>> So when gssproxy.service does it's "Before=nfs-secure.service
> >>>> nfs-secure-server.service" line everything is loaded before
> >>>> gssproxy start... 
> >>>>
> >>>> I'm think gssproxy.service just needs to the put the Wants and
> >>>> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that Before
> >>>> line.. 
> >>>
> >>> Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
> >>> to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention
> >>> of nfs services in gssproxy unit file so you have complete control
> >>> of the dependencies ?
> >> No. 
> >> The loading of sunrpc and the mounting of the file system has
> >> nothing to do with starting up the gssd daemons.
> >>
> >> I would suggest gssproxy does to two things:
> >>
> >> 1) Add a Requires: nfs-utils to the spec file since you are
> >> requiring services from  nfs-utils
> > 
> > No we are not requiring services from nfs-utils, nfs-utils is one of
> > our users, you got that reversed.
> So having "Before=nfs-secure.service nfs-secure-server.service" in 
> gssproxy.service and not having nfs-utils installed will not cause the
> service fail during start up? 

It will not, but right now gssproxy.service also has:
 Requires=proc-fs-nfsd.mount

I want to drop this one.

> >> 2) Add a After=var-lib-nfs-rpc_pipefs.mount to the
> >> gssproxy.service file since gssproxy could careless about either
> >> rpc.gssd or rpc.svcgssd daemons. All it is looking for is the
> >> sunrpc and auth_rpcgss kernel modules.
> > 
> > The correct thing is to add a Before: gssproxy.service to
> > var-lib-nfs-rpc_pipefs.mount IMO.
> Again what happen if gssproxy is not installed? Things will 
> still come up successfully?

Yes, afaik After and Before are just ordering instruction and do not
cause any failure if the units are not present at all, or fail to start.

There are Want and Require directives for strong relationships.

Simo.

Steve Dickson Sept. 23, 2014, 2:58 p.m. UTC | #23

On 09/23/2014 08:52 AM, Simo Sorce wrote:
> On Mon, 22 Sep 2014 21:19:18 -0400
> Steve Dickson <[e-mail]> wrote:
> 
>>
>>
>> On 09/22/2014 08:19 PM, Simo Sorce wrote:
>>> On Mon, 22 Sep 2014 18:57:10 -0400
>>> Steve Dickson <[e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On 09/22/2014 05:32 PM, Simo Sorce wrote:
>>>>> On Mon, 22 Sep 2014 17:14:05 -0400
>>>>> Steve Dickson <[e-mail]> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
>>>>>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
>>>>>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
>>>>>>>>> Steve Dickson <[e-mail]> 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.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
>>>>>>>>>> ---
>>>>>>>>>>  systemd/nfs-server.service | 5 +++--
>>>>>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/systemd/nfs-server.service
>>>>>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
>>>>>>>>>> --- a/systemd/nfs-server.service
>>>>>>>>>> +++ b/systemd/nfs-server.service
>>>>>>>>>> @@ -2,12 +2,13 @@
>>>>>>>>>>  Description=NFS server and services
>>>>>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>>>>>  Requires= nfs-mountd.service
>>>>>>>>>> -Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service
>>>>>>>>>> rpc-svcgssd.service +Wants=rpc-statd.service
>>>>>>>>>> nfs-idmapd.service +Wants=rpc-gssd.service  
>>>>>>>>>>  Wants=rpc-statd-notify.service
>>>>>>>>>>  
>>>>>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
>>>>>>>>>> nfs-mountd.service After= nfs-idmapd.service
>>>>>>>>>> rpc-statd.service -After= rpc-gssd.service
>>>>>>>>>> rpc-svcgssd.service +After= rpc-gssd.service
>>>>>>>>>> gssproxy.service rpc-svcgssd.service Before=
>>>>>>>>>> rpc-statd-notify.service 
>>>>>>>>>>  Wants=nfs-config.service
>>>>>>>>>
>>>>>>>>> I think you really need to insure that the modules are loaded
>>>>>>>>> before any of the server services are started, perhaps adding
>>>>>>>>> a unit file that exec's modprobe and has "Before:
>>>>>>>>> gssproxy.service " in it ?
>>>>>>>> I really don't think its needed... From my testing it appears 
>>>>>>>> gssproxy is always being started and rpc.svcgssd is not... 
>>>>>>>
>>>>>>> Huh.  Well rpc-svcgssd.service has var-lib-nfs-rpc_pipefs.mount
>>>>>>> as both "Requires=" and "After=", so rpc-svcgssd.service will
>>>>>>> never run without first running var-lib-nfs-rpc_pipefs.mount,
>>>>>>> which will load sunrpc.  But I don't see where auth_rpcgss is
>>>>>>> getting loaded.  And I don't see what ensures anything
>>>>>>> happening before gssproxy runs.
>>>>>> It happens during the mount on the client and when the server
>>>>>> is started. 
>>>>>>
>>>>>>>
>>>>>>> We want to make sure your testing's not just getting lucky on
>>>>>>> the startup order.
>>>>>> The reason it working is because rpc.gssd is being started on the
>>>>>> server these days for callbacks and the After= line in
>>>>>> rpc-svcgssd.service is being executed before the
>>>>>> ConditionPathExists which cause rpc.svcgssd not to start.
>>>>>
>>>>> This guarantees ordering (to some degree) between rpc.gssd and
>>>>> rpoc.svcgssd, but says nothing about gssproxy ...
>>>> The question was how is the auth_rpcgss module being loaded. Since
>>>> both rpc-svcgssd.service and rpc-gssd.service service have
>>>> a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
>>>> them, that's how auth_rpcgss is being loaded. 
>>>>
>>>> If you only in enable gssproxy (not nfs-server or nfs-client) the 
>>>> module still get loaded via gssproxy,service file 
>>>>
>>>>>> So when gssproxy.service does it's "Before=nfs-secure.service
>>>>>> nfs-secure-server.service" line everything is loaded before
>>>>>> gssproxy start... 
>>>>>>
>>>>>> I'm think gssproxy.service just needs to the put the Wants and
>>>>>> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that Before
>>>>>> line.. 
>>>>>
>>>>> Maybe we should add "Before: gssproxy.service rpc-svcgssd.service"
>>>>> to var-lib-nfs-rpc_pipefs.mount instead (and also drop any mention
>>>>> of nfs services in gssproxy unit file so you have complete control
>>>>> of the dependencies ?
>>>> No. 
>>>> The loading of sunrpc and the mounting of the file system has
>>>> nothing to do with starting up the gssd daemons.
>>>>
>>>> I would suggest gssproxy does to two things:
>>>>
>>>> 1) Add a Requires: nfs-utils to the spec file since you are
>>>> requiring services from  nfs-utils
>>>
>>> No we are not requiring services from nfs-utils, nfs-utils is one of
>>> our users, you got that reversed.
>> So having "Before=nfs-secure.service nfs-secure-server.service" in 
>> gssproxy.service and not having nfs-utils installed will not cause the
>> service fail during start up? 
> 
> It will not, but right now gssproxy.service also has:
>  Requires=proc-fs-nfsd.mount
> 
> I want to drop this one.
You don't want to drop this because it loads the needed kernel modules.

> 
>>>> 2) Add a After=var-lib-nfs-rpc_pipefs.mount to the
>>>> gssproxy.service file since gssproxy could careless about either
>>>> rpc.gssd or rpc.svcgssd daemons. All it is looking for is the
>>>> sunrpc and auth_rpcgss kernel modules.
>>>
>>> The correct thing is to add a Before: gssproxy.service to
>>> var-lib-nfs-rpc_pipefs.mount IMO.
>> Again what happen if gssproxy is not installed? Things will 
>> still come up successfully?
> 
> Yes, afaik After and Before are just ordering instruction and do not
> cause any failure if the units are not present at all, or fail to start.
Ok... thanks! 

steved. 
> 
> There are Want and Require directives for strong relationships.
> 
> Simo.
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 23, 2014, 3:08 p.m. UTC | #24

On Tue, 23 Sep 2014 10:58:38 -0400
Steve Dickson <[e-mail]> wrote:

> 
> 
> On 09/23/2014 08:52 AM, Simo Sorce wrote:
> > On Mon, 22 Sep 2014 21:19:18 -0400
> > Steve Dickson <[e-mail]> wrote:
> > 
> >>
> >>
> >> On 09/22/2014 08:19 PM, Simo Sorce wrote:
> >>> On Mon, 22 Sep 2014 18:57:10 -0400
> >>> Steve Dickson <[e-mail]> wrote:
> >>>
> >>>>
> >>>>
> >>>> On 09/22/2014 05:32 PM, Simo Sorce wrote:
> >>>>> On Mon, 22 Sep 2014 17:14:05 -0400
> >>>>> Steve Dickson <[e-mail]> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 09/22/2014 04:44 PM, J. Bruce Fields wrote:
> >>>>>>> On Mon, Sep 22, 2014 at 03:43:09PM -0400, Steve Dickson wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 09/22/2014 03:26 PM, Simo Sorce wrote:
> >>>>>>>>> On Mon, 22 Sep 2014 15:20:07 -0400
> >>>>>>>>> Steve Dickson <[e-mail]> 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.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Steve Dickson <[e-mail]>
> >>>>>>>>>> ---
> >>>>>>>>>>  systemd/nfs-server.service | 5 +++--
> >>>>>>>>>>  1 file changed, 3 insertions(+), 2 deletions(-)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/systemd/nfs-server.service
> >>>>>>>>>> b/systemd/nfs-server.service index 2fa7387..c740fa2 100644
> >>>>>>>>>> --- a/systemd/nfs-server.service
> >>>>>>>>>> +++ b/systemd/nfs-server.service
> >>>>>>>>>> @@ -2,12 +2,13 @@
> >>>>>>>>>>  Description=NFS server and services
> >>>>>>>>>>  Requires= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>>>>>  Requires= nfs-mountd.service
> >>>>>>>>>> -Wants=rpc-statd.service nfs-idmapd.service
> >>>>>>>>>> rpc-gssd.service rpc-svcgssd.service
> >>>>>>>>>> +Wants=rpc-statd.service nfs-idmapd.service
> >>>>>>>>>> +Wants=rpc-gssd.service Wants=rpc-statd-notify.service
> >>>>>>>>>>  
> >>>>>>>>>>  After= network.target proc-fs-nfsd.mount rpcbind.target
> >>>>>>>>>> nfs-mountd.service After= nfs-idmapd.service
> >>>>>>>>>> rpc-statd.service -After= rpc-gssd.service
> >>>>>>>>>> rpc-svcgssd.service +After= rpc-gssd.service
> >>>>>>>>>> gssproxy.service rpc-svcgssd.service Before=
> >>>>>>>>>> rpc-statd-notify.service 
> >>>>>>>>>>  Wants=nfs-config.service
> >>>>>>>>>
> >>>>>>>>> I think you really need to insure that the modules are
> >>>>>>>>> loaded before any of the server services are started,
> >>>>>>>>> perhaps adding a unit file that exec's modprobe and has
> >>>>>>>>> "Before: gssproxy.service " in it ?
> >>>>>>>> I really don't think its needed... From my testing it
> >>>>>>>> appears gssproxy is always being started and rpc.svcgssd is
> >>>>>>>> not... 
> >>>>>>>
> >>>>>>> Huh.  Well rpc-svcgssd.service has
> >>>>>>> var-lib-nfs-rpc_pipefs.mount as both "Requires=" and
> >>>>>>> "After=", so rpc-svcgssd.service will never run without first
> >>>>>>> running var-lib-nfs-rpc_pipefs.mount, which will load
> >>>>>>> sunrpc.  But I don't see where auth_rpcgss is getting
> >>>>>>> loaded.  And I don't see what ensures anything happening
> >>>>>>> before gssproxy runs.
> >>>>>> It happens during the mount on the client and when the server
> >>>>>> is started. 
> >>>>>>
> >>>>>>>
> >>>>>>> We want to make sure your testing's not just getting lucky on
> >>>>>>> the startup order.
> >>>>>> The reason it working is because rpc.gssd is being started on
> >>>>>> the server these days for callbacks and the After= line in
> >>>>>> rpc-svcgssd.service is being executed before the
> >>>>>> ConditionPathExists which cause rpc.svcgssd not to start.
> >>>>>
> >>>>> This guarantees ordering (to some degree) between rpc.gssd and
> >>>>> rpoc.svcgssd, but says nothing about gssproxy ...
> >>>> The question was how is the auth_rpcgss module being loaded.
> >>>> Since both rpc-svcgssd.service and rpc-gssd.service service have
> >>>> a After=var-lib-nfs-rpc_pipefs.mount and gssproxy is requiring 
> >>>> them, that's how auth_rpcgss is being loaded. 
> >>>>
> >>>> If you only in enable gssproxy (not nfs-server or nfs-client)
> >>>> the module still get loaded via gssproxy,service file 
> >>>>
> >>>>>> So when gssproxy.service does it's "Before=nfs-secure.service
> >>>>>> nfs-secure-server.service" line everything is loaded before
> >>>>>> gssproxy start... 
> >>>>>>
> >>>>>> I'm think gssproxy.service just needs to the put the Wants and
> >>>>>> After= var-lib-nfs-rpc_pipefs.mount lines, instead of that
> >>>>>> Before line.. 
> >>>>>
> >>>>> Maybe we should add "Before: gssproxy.service
> >>>>> rpc-svcgssd.service" to var-lib-nfs-rpc_pipefs.mount instead
> >>>>> (and also drop any mention of nfs services in gssproxy unit
> >>>>> file so you have complete control of the dependencies ?
> >>>> No. 
> >>>> The loading of sunrpc and the mounting of the file system has
> >>>> nothing to do with starting up the gssd daemons.
> >>>>
> >>>> I would suggest gssproxy does to two things:
> >>>>
> >>>> 1) Add a Requires: nfs-utils to the spec file since you are
> >>>> requiring services from  nfs-utils
> >>>
> >>> No we are not requiring services from nfs-utils, nfs-utils is one
> >>> of our users, you got that reversed.
> >> So having "Before=nfs-secure.service nfs-secure-server.service" in 
> >> gssproxy.service and not having nfs-utils installed will not cause
> >> the service fail during start up? 
> > 
> > It will not, but right now gssproxy.service also has:
> >  Requires=proc-fs-nfsd.mount
> > 
> > I want to drop this one.
> You don't want to drop this because it loads the needed kernel
> modules.

I want the unit file Bruce proposed to require this and to be run before
gssproxy.service
Once we have that unit I can drop mine which has always been just a
workaround.

Simo.

J. Bruce Fields Sept. 23, 2014, 7:29 p.m. UTC | #25

On Tue, Sep 23, 2014 at 08:52:45AM -0400, Simo Sorce wrote:
> It will not, but right now gssproxy.service also has:
>  Requires=proc-fs-nfsd.mount
> 
> I want to drop this one.

By the way, I think all you actually want is After=proc-fs-nfsd.mount.

You don't actually want to bail out if fs-nfsd.mount fails, in fact you
don't care if it's activated at all, all you care about is that *if*
it's already activated (because nfsd is), then you want it to start
before you.

And in fact we could instead replace that with a Before=gssproxy.service
in proc-fs-nfsd.mount if you preferred.  I don't know how to decide
which place it goes, or if it matters.

--b.

> 
> > >> 2) Add a After=var-lib-nfs-rpc_pipefs.mount to the
> > >> gssproxy.service file since gssproxy could careless about either
> > >> rpc.gssd or rpc.svcgssd daemons. All it is looking for is the
> > >> sunrpc and auth_rpcgss kernel modules.
> > > 
> > > The correct thing is to add a Before: gssproxy.service to
> > > var-lib-nfs-rpc_pipefs.mount IMO.
> > Again what happen if gssproxy is not installed? Things will 
> > still come up successfully?
> 
> Yes, afaik After and Before are just ordering instruction and do not
> cause any failure if the units are not present at all, or fail to start.
> 
> There are Want and Require directives for strong relationships.
> 
> 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 [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simo Sorce Sept. 23, 2014, 7:40 p.m. UTC | #26

On Tue, 23 Sep 2014 15:29:09 -0400
"J. Bruce Fields" <[e-mail]> wrote:

> On Tue, Sep 23, 2014 at 08:52:45AM -0400, Simo Sorce wrote:
> > It will not, but right now gssproxy.service also has:
> >  Requires=proc-fs-nfsd.mount
> > 
> > I want to drop this one.
> 
> By the way, I think all you actually want is After=proc-fs-nfsd.mount.
> 
> You don't actually want to bail out if fs-nfsd.mount fails, in fact
> you don't care if it's activated at all, all you care about is that
> *if* it's already activated (because nfsd is), then you want it to
> start before you.
> 
> And in fact we could instead replace that with a
> Before=gssproxy.service in proc-fs-nfsd.mount if you preferred.  I
> don't know how to decide which place it goes, or if it matters.

Given we are already messing with service files I wouldn't object to
moving the depenecy chain creation in nfs-util by adding a
Before=gssproxy.service directive in proc-fs-nfsd.mount and dropping
the Reuire from gssproxy.service

Simo.

J. Bruce Fields Sept. 23, 2014, 7:51 p.m. UTC | #27

On Tue, Sep 23, 2014 at 03:40:36PM -0400, Simo Sorce wrote:
> On Tue, 23 Sep 2014 15:29:09 -0400
> "J. Bruce Fields" <[e-mail]> wrote:
> 
> > On Tue, Sep 23, 2014 at 08:52:45AM -0400, Simo Sorce wrote:
> > > It will not, but right now gssproxy.service also has:
> > >  Requires=proc-fs-nfsd.mount
> > > 
> > > I want to drop this one.
> > 
> > By the way, I think all you actually want is After=proc-fs-nfsd.mount.
> > 
> > You don't actually want to bail out if fs-nfsd.mount fails, in fact
> > you don't care if it's activated at all, all you care about is that
> > *if* it's already activated (because nfsd is), then you want it to
> > start before you.
> > 
> > And in fact we could instead replace that with a
> > Before=gssproxy.service in proc-fs-nfsd.mount if you preferred.  I
> > don't know how to decide which place it goes, or if it matters.
> 
> Given we are already messing with service files I wouldn't object to
> moving the depenecy chain creation in nfs-util by adding a
> Before=gssproxy.service directive in proc-fs-nfsd.mount and dropping
> the Reuire from gssproxy.service

Wella ctually we should add the auth-rpcgss unit (which includes the
necessary Before).  But you might want to s/Requires=/After=/ meanwhile
as the current thing seems possibly unreliable (since there's no
ordering dependency).

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to [e-mail]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/systemd/nfs-server.service b/systemd/nfs-server.service
index 2fa7387..c740fa2 100644
--- a/systemd/nfs-server.service
+++ b/systemd/nfs-server.service
@@ -2,12 +2,13 @@ 
 Description=NFS server and services
 Requires= network.target proc-fs-nfsd.mount rpcbind.target
 Requires= nfs-mountd.service
-Wants=rpc-statd.service nfs-idmapd.service rpc-gssd.service rpc-svcgssd.service
+Wants=rpc-statd.service nfs-idmapd.service 
+Wants=rpc-gssd.service gssproxy.service rpc-svcgssd.service
 Wants=rpc-statd-notify.service
 
 After= network.target proc-fs-nfsd.mount rpcbind.target nfs-mountd.service
 After= nfs-idmapd.service rpc-statd.service
-After= rpc-gssd.service rpc-svcgssd.service
+After= rpc-gssd.service gssproxy.service rpc-svcgssd.service
 Before= rpc-statd-notify.service
 
 Wants=nfs-config.service