GNU bug report logs -
#43257
[PATCH] services: nfs: Require file-systems to be mounted before starting NFS shepherd service.
Previous Next
To reply to this bug, email your comments to 43257 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Mon, 07 Sep 2020 16:48:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Danny Milosavljevic <dannym <at> scratchpost.org>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Mon, 07 Sep 2020 16:48:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* 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(-)
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")))
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Wed, 09 Sep 2020 08:28:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 43257 <at> debbugs.gnu.org (full text, mbox):
Hey!
Danny Milosavljevic <dannym <at> 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’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Wed, 09 Sep 2020 10:14:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 43257 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
On Wed, 09 Sep 2020 10:27:30 +0200
Ludovic Courtès <ludo <at> 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?
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Thu, 10 Sep 2020 07:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 43257 <at> debbugs.gnu.org (full text, mbox):
Hi Danny,
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> On Wed, 09 Sep 2020 10:27:30 +0200
> Ludovic Courtès <ludo <at> 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’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Thu, 10 Sep 2020 13:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 43257 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
On Thu, 10 Sep 2020 09:42:58 +0200
Ludovic Courtès <ludo <at> 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.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Fri, 11 Sep 2020 07:03:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 43257 <at> debbugs.gnu.org (full text, mbox):
Howdy,
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> On Thu, 10 Sep 2020 09:42:58 +0200
> Ludovic Courtès <ludo <at> 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’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Fri, 11 Sep 2020 08:24:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 43257 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
On Fri, 11 Sep 2020 09:02:09 +0200
Ludovic Courtès <ludo <at> 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?
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Fri, 11 Sep 2020 14:48:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 43257 <at> debbugs.gnu.org (full text, mbox):
Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> Hi Ludo,
>
> On Fri, 11 Sep 2020 09:02:09 +0200
> Ludovic Courtès <ludo <at> 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’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Fri, 11 Sep 2020 17:51:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 43257 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Ludo,
On Fri, 11 Sep 2020 16:47:14 +0200
Ludovic Courtès <ludo <at> 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.
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#43257
; Package
guix-patches
.
(Sun, 13 Sep 2020 19:54:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 43257 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?)
[Message part 2 (application/pgp-signature, inline)]
This bug report was last modified 4 years and 272 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.