diff mbox series

[bug#43257] services: nfs: Require file-systems to be mounted before starting NFS shepherd service.

Message ID 20200907164745.15932-1-dannym@scratchpost.org
State New
Headers show
Series [bug#43257] services: nfs: Require file-systems to be mounted before starting NFS shepherd service. | expand

Checks

Context Check Description
cbaines/comparison success View comparision
cbaines/git branch success View Git branch
cbaines/applying patch success View Laminar job

Commit Message

Danny Milosavljevic Sept. 7, 2020, 4:47 p.m. UTC
* gnu/services/nfs.scm (nfs-shepherd-services): Require file-systems to be
mounted before starting NFS shepherd service.
---
 gnu/services/nfs.scm | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Comments

Ludovic Courtès Sept. 9, 2020, 8:27 a.m. UTC | #1
Hey!

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> * gnu/services/nfs.scm (nfs-shepherd-services): Require file-systems to be
> mounted before starting NFS shepherd service.

[...]

> +++ b/gnu/services/nfs.scm
> @@ -292,7 +292,7 @@
>            (shepherd-service
>             (documentation "Run the NFS statd daemon.")
>             (provision '(rpc.statd))
> -           (requirement '(/proc/fs/nfsd rpcbind-daemon))
> +           (requirement '(/proc/fs/nfsd rpcbind-daemon file-systems))

Why do we need all of ‘file-systems’ rather than just the state file
systems?

Curiously,
Ludo’.
Danny Milosavljevic Sept. 9, 2020, 10:13 a.m. UTC | #2
Hi Ludo,

On Wed, 09 Sep 2020 10:27:30 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Why do we need all of ‘file-systems’ rather than just the state file
> systems?

It really depends on what one uses it for, but for me it's this use case:

* I have an extra hard drive that contains things I want to serve via
NFS (it has nothing to do with the root file system).
* The extra hard drive has to be mounted when NFS service starts up,
otherwise exportfs errors out:
If I don't require "file-systems", even if that drive is listed in the
operating-system's file-systems list, it won't be mounted in time.

I ran into this problem when merging Stefan's 
new "nfs-root-fs" system test into gnu/tests/nfs.scm .

Does this make sense or is it the wrong solution?
Ludovic Courtès Sept. 10, 2020, 7:42 a.m. UTC | #3
Hi Danny,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Wed, 09 Sep 2020 10:27:30 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Why do we need all of ‘file-systems’ rather than just the state file
>> systems?
>
> It really depends on what one uses it for, but for me it's this use case:
>
> * I have an extra hard drive that contains things I want to serve via
> NFS (it has nothing to do with the root file system).
> * The extra hard drive has to be mounted when NFS service starts up,
> otherwise exportfs errors out:
> If I don't require "file-systems", even if that drive is listed in the
> operating-system's file-systems list, it won't be mounted in time.

Oh, I see.

> I ran into this problem when merging Stefan's 
> new "nfs-root-fs" system test into gnu/tests/nfs.scm .
>
> Does this make sense or is it the wrong solution?

I just realized that these services should just all depend on
‘user-processes’ (which depends on ‘file-systems’).  So you should
probably just do that.

You can double-check with ‘guix system shepherd-graph’ that the
dependency graph looks good.

Thanks,
Ludo’.
Danny Milosavljevic Sept. 10, 2020, 1:20 p.m. UTC | #4
Hi Ludo,

On Thu, 10 Sep 2020 09:42:58 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> I just realized that these services should just all depend on
> ‘user-processes’ (which depends on ‘file-systems’).  So you should
> probably just do that.

Okay.  Thanks.

> You can double-check with ‘guix system shepherd-graph’ that the
> dependency graph looks good.

$ ./pre-inst-env guix system shepherd-graph -e '(@@ (gnu tests nfs) %nfs-os)'
gnu/tests/nfs.scm:162:4: error: missing root file system

I can probably work around it somehow--but just logging this not-nice user
interface here.
Ludovic Courtès Sept. 11, 2020, 7:02 a.m. UTC | #5
Howdy,

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> On Thu, 10 Sep 2020 09:42:58 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> I just realized that these services should just all depend on
>> ‘user-processes’ (which depends on ‘file-systems’).  So you should
>> probably just do that.
>
> Okay.  Thanks.
>
>> You can double-check with ‘guix system shepherd-graph’ that the
>> dependency graph looks good.
>
> $ ./pre-inst-env guix system shepherd-graph -e '(@@ (gnu tests nfs) %nfs-os)'
> gnu/tests/nfs.scm:162:4: error: missing root file system
>
> I can probably work around it somehow--but just logging this not-nice user
> interface here.

Any suggestions?  :-)

The only think I could think of is transparently adding a dummy root
file system for the purposes of ‘shepherd-graph’, but it’s not
necessarily a good idea either.

Thanks,
Ludo’.
Danny Milosavljevic Sept. 11, 2020, 8:23 a.m. UTC | #6
Hi Ludo,

On Fri, 11 Sep 2020 09:02:09 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> Any suggestions?  :-)
> 
> The only think I could think of is transparently adding a dummy root
> file system for the purposes of ‘shepherd-graph’, but it’s not
> necessarily a good idea either.

It depends on whether we want to have developer tools--but if we do, it would
be nice to be more forgiving on some errors (for example have a "developer"
switch that would add missing fields if they are harmless and don't change
the result.  Or maybe just have a procedure available that would do that
which the dev could add a call to with "-e").

That said, not sure that it's a good idea.

I'm just always logging weird things so we actually can see them.

It's not necessarily something we can (or should) fix :-)

However, this %nfs-os is used almost unchanged for marionette-operating-system.

So I got this idea:

$ ./pre-inst-env guix system shepherd-graph -e '((@ (gnu tests) marionette-operating-system) (@@ (gnu tests nfs) %nfs-os)))'
gnu/tests.scm:161:2: error: missing root file system

... doesn't work either.  Well now that's weird.

That operating-system is eventually passed to "virtual-machine".

So that means we can't use shepherd-graph on VMs?
Ludovic Courtès Sept. 11, 2020, 2:47 p.m. UTC | #7
Danny Milosavljevic <dannym@scratchpost.org> skribis:

> Hi Ludo,
>
> On Fri, 11 Sep 2020 09:02:09 +0200
> Ludovic Courtès <ludo@gnu.org> wrote:
>
>> Any suggestions?  :-)
>> 
>> The only think I could think of is transparently adding a dummy root
>> file system for the purposes of ‘shepherd-graph’, but it’s not
>> necessarily a good idea either.
>
> It depends on whether we want to have developer tools--but if we do, it would
> be nice to be more forgiving on some errors (for example have a "developer"
> switch that would add missing fields if they are harmless and don't change
> the result.  Or maybe just have a procedure available that would do that
> which the dev could add a call to with "-e").
>
> That said, not sure that it's a good idea.
>
> I'm just always logging weird things so we actually can see them.
>
> It's not necessarily something we can (or should) fix :-)
>
> However, this %nfs-os is used almost unchanged for marionette-operating-system.
>
> So I got this idea:
>
> $ ./pre-inst-env guix system shepherd-graph -e '((@ (gnu tests) marionette-operating-system) (@@ (gnu tests nfs) %nfs-os)))'
> gnu/tests.scm:161:2: error: missing root file system
>
> ... doesn't work either.  Well now that's weird.
>
> That operating-system is eventually passed to "virtual-machine".
>
> So that means we can't use shepherd-graph on VMs?

No: that just means that ‘virtualized-operating-system’ adds a root file
system transparently, which is why we can afford not providing one in
OSes that are only meant to be used through ‘guix system vm’.

But ‘shepherd-graph’ doesn’t know about that: it takes your OS as is and
show you the info.

Hope that makes sense!

Ludo’.
Danny Milosavljevic Sept. 11, 2020, 5:50 p.m. UTC | #8
Hi Ludo,

On Fri, 11 Sep 2020 16:47:14 +0200
Ludovic Courtès <ludo@gnu.org> wrote:

> No: that just means that ‘virtualized-operating-system’ adds a root file
> system transparently, which is why we can afford not providing one in
> OSes that are only meant to be used through ‘guix system vm’.
> 
> But ‘shepherd-graph’ doesn’t know about that: it takes your OS as is and
> show you the info.

That makes sense.

So that means a user/developer can't use shepherd-graph on VMs :P

That's a very bad user interface.

Especially since if you are using shepherd-graph chances are you already are
diagnosing a problem and don't want to have to diagnose more problems first
in order to solve that one.

Personally I'd make it emit a warning and add a rootfs if it's harmless in
order to have this usecase (using shepherd-graph on VMs) be supported.  If
we want that.

But it's fine for now--I just wanted to make sure to point out the pain points.
Danny Milosavljevic Sept. 13, 2020, 7:52 p.m. UTC | #9
Hi,

I've got some spooky problem in the NFS root test (or in the VM setup by Guix,
really).

It seems to hang the system test in a part I cannot change (so it's not inside
the test script).

In order to reproduce, start with guix master commit
898fbb60b2354e82e5b7f259b44dbfed112a83aa--or any recent Guix master commit.

So far it's still "fine"-ish:

$ make TESTS="nfs-root-fs" check-system
[... works fine and eventually fails because port 20001 is waited for but is
never opened by the server--so far so good]

Now edit gnu/tests/nfs.scm to change

 ;(rpcmountd-port 20001)

to

 (rpcmountd-port 20001)

in order to fix the problem above--or so I thought.

$ make TESTS="nfs-root-fs" check-system
[... hangs in first VM--without even trying to start up the NFS server VM (as
far as I can tell)]

What is going on?  Also, how to debug this?

(same happens when enabling (rpcstatd-port 20002) only.
Also, doesn't rpcstatd have TWO ports--one to broadcast and one to listen?
How does one set up both using the operating-system configuration?)
diff mbox series

Patch

diff --git a/gnu/services/nfs.scm b/gnu/services/nfs.scm
index 859097e788..24f746485b 100644
--- a/gnu/services/nfs.scm
+++ b/gnu/services/nfs.scm
@@ -292,7 +292,7 @@ 
           (shepherd-service
            (documentation "Run the NFS statd daemon.")
            (provision '(rpc.statd))
-           (requirement '(/proc/fs/nfsd rpcbind-daemon))
+           (requirement '(/proc/fs/nfsd rpcbind-daemon file-systems))
            (start
             #~(make-forkexec-constructor
                (list #$(file-append nfs-utils "/sbin/rpc.statd")
@@ -311,7 +311,7 @@ 
           (shepherd-service
            (documentation "Run the NFS mountd daemon.")
            (provision '(rpc.mountd))
-           (requirement '(/proc/fs/nfsd rpc.statd))
+           (requirement '(/proc/fs/nfsd rpc.statd file-systems))
            (start
             #~(make-forkexec-constructor
                (list #$(file-append nfs-utils "/sbin/rpc.mountd")
@@ -326,7 +326,7 @@ 
           (shepherd-service
            (documentation "Run the NFS daemon.")
            (provision '(rpc.nfsd))
-           (requirement '(/proc/fs/nfsd rpc.statd networking))
+           (requirement '(/proc/fs/nfsd rpc.statd networking file-systems))
            (start
             #~(lambda _
                 (zero? (apply system* #$(file-append nfs-utils "/sbin/rpc.nfsd")
@@ -352,7 +352,7 @@ 
           (shepherd-service
            (documentation "Run the NFS mountd daemon and refresh exports.")
            (provision '(nfs))
-           (requirement '(/proc/fs/nfsd rpc.nfsd rpc.mountd rpc.statd rpcbind-daemon))
+           (requirement '(/proc/fs/nfsd rpc.nfsd rpc.mountd rpc.statd rpcbind-daemon file-systems))
            (start
             #~(lambda _
                 (let ((rpcdebug #$(file-append nfs-utils "/sbin/rpcdebug")))