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 |
Context | Check | Description |
---|---|---|
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
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’.
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?
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’.
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.
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’.
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?
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’.
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.
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 --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")))