From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: (Exposing?) config files and non-start/stop operations Date: Tue, 22 Nov 2016 11:21:22 -0600 Message-ID: <87r363a0rx.fsf@dustycloud.org> References: <87a8cuaszg.fsf@dustycloud.org> <878tsdbx2d.fsf@dustycloud.org> <87polpo2k4.fsf@gmail.com> <877f7wbyc7.fsf@dustycloud.org> <874m30bwpv.fsf@dustycloud.org> <87k2bwxibv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52082) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9El5-0002ur-TW for guix-devel@gnu.org; Tue, 22 Nov 2016 12:21:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c9El2-0007Nm-KG for guix-devel@gnu.org; Tue, 22 Nov 2016 12:21:27 -0500 Received: from dustycloud.org ([50.116.34.160]:39592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c9El2-0007NS-FX for guix-devel@gnu.org; Tue, 22 Nov 2016 12:21:24 -0500 In-reply-to: <87k2bwxibv.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel@gnu.org Chris Marusich writes: > Hi Chris! > > Thanks for entertaining my questions. > > Christopher Allan Webber 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