guix-devel
[Top][All Lists]
Advanced

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

Re: (Exposing?) config files and non-start/stop operations


From: Christopher Allan Webber
Subject: Re: (Exposing?) config files and non-start/stop operations
Date: Tue, 22 Nov 2016 11:21:22 -0600
User-agent: mu4e 0.9.16; emacs 25.1.1

Chris Marusich writes:

> Hi Chris!
>
> Thanks for entertaining my questions.
>
> Christopher Allan Webber <address@hidden> writes:
>
>>> So sure, we can run "foo-db gc" occasionally (though system
>>> administrators sometimes have to run these kinds of commands by hand).
>>> But what about "foo-db dumpdb"?  That's not something we just run on a
>>> cronjob.  You need access to that command.  And in order for the command
>>> to do the right thing, it might need access to the config file.
>
> I'm having trouble understanding the motivation here.  Can you clarify
> why it's preferable to model the action as a Shepherd action, even
> though a mechanism already exists to perform the action (e.g., "foo-db
> dumpdb")?
>
> I don't know a lot about Shepherd (yet!), but it seems like you COULD
> model the action as a Shepherd action.  The question is: WHY would that
> be better than just performing the action via "the usual" mechanism?  If
> you can provide a more concrete example which illustrates the problem
> for a specific service/daemon, it might help me to understand where
> you're coming from.

Sure, sorry I'm not being clear.

So say you wanted to run `foo-db dumpdb'.  Now while most foo-db setups
point to /var/lib/foodb/, you have your foo-db setup mounted on some
external or network storage or something, so it's mounted at
/mnt/dbdisk/foodb/.  With me so far?

And here's how we configured that, in our GuixSD configuration:

  (operating-system
    ;; ...
    (services (foo-db-service #:path "/mnt/dbdisk/foodb")))

Okay, cool!  So the way this works is that the foo-db-service procedure
sets up the service so that it passes in a configuration file that it
generated with the path set appropriately, as above.  So when shepherd
starts/stops this service, it uses this config, and it knows where the
data is.  (It probably does something like
  `foo-db run --config=/gnu/store/.../foodb.cfg')

So now you want to back up the database manually.  No problem!  You have
that `foo-db dumpdb' command.

But you run it... and it doesn't work!  foo-db assumed that your data
would be in the default location, /var/lib/foodb/.  The command you
*want* to run is something like:

  `foo-db dumpdb --config=/path/to/foodb.cfg'

Now... your GuixSD system has, somewhere buried in it, a config file
that it passes in when shepherd starts/stops the daemon.  It's somewhere
in /gnu/store/ ... but you don't know where it is!  GuixSD has cleverly
provided this config file to the closure of its own daemon managing
environment, but has given you no way to access it.

So when you try to back up your database, too bad!  It won't work!

Does that make sense now?

Anyway, I think exposing the `actions' slot in shepherd is the way to
go.  We could already use it for some things other than the theoretical
examples I've given.  Last night I wanted to do something like:

  sudo mcron --schedule=10

... which would, according to the mcron docs, show me the next ten
upcoming tasks that are scheduled!  I wanted to verify that I was
writing my mcron procedures right.  Likewise, my shepherd configuration
seems obscured (well sort of, I can figure it out by looking at
`ps auwwwx' but I don't want to do that).  It would be nice if I could
do:

  sudo herd list-schedule mcron 10

Anyway, hopefully I've made my case! :)
 
 - Chris



reply via email to

[Prev in Thread] Current Thread [Next in Thread]