Re: another distro using runit...

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Mon, 20 Oct 2014 17:02:56 -0700

On Mon, Oct 20, 2014 at 10:52 AM, John Albietz <inthecloud247_at_gmail.com>
wrote:
>
>
> Re: runit, a few things I've run into:
> - I haven't found a way to lower the default wait time on init start from
> the current default 1 second. Also not sure if there's a way to lower the
> runsvdir service poll timer below 1 second?
>

Just curious - why under 1 second?


> - With nearly all of my services, I create enable scripts that check for,
> and if necessary set up directories and perhaps even default passwords or
> databases.


Most (process)/run scripts will support the pre-run environment setup, such
as creating /var/run/(process) directories, or setting up special files.
Usually this takes the form of a check for the directory/file, and if it
isn't there, it creates it.


> And I haven't found an elegant way yet to integrate this into
> runit. I think it would be useful to separate out a command for 'enable'
> that would run successfully only once for a service.


This is entirely possible, provided your file(s) don't conflict with other
packagers or arrangements. Keep in mind that runit is a re-imagined
version of djb daemontools. There are others like s6 that also qualify in
this "arrangement". It wouldn't take much to make your efforts portable
between these frameworks.


> Or I guess I can
> create some idempotent test that runs before each service run command.


Exactly. This could be as easy as doing ' [ -f ./foo ] || do-something &&
touch ./foo ' in your startup script.


> But
> that doesn't seem as elegant.


I guess we should define elegant? For some people, seeing a file is
elegant. The runit approach is file-centric and it would seem likely (to me
at least) to keep with the same file-and-symlink approach to dealing with
the service definition.


> Unit already has a concept of a 'check' file
> and a 'finish' file. What do you think about adding support for a 'enable',
> 'start' or 'pre' file that only gets run on service start?
>

We have a post-start hook in the form of (service)/finish; a pre-start hook
may or may not be needed, given that the (service)/run script typically
handles all of the pre-start requirements.

You could also make an arrangement where you issue a run-once, which does
the preliminary setup, and then run it normally. Upon exit the first time,
a setup flag is placed in the service directory and it will know to skip
the preliminary setup. Not a great solution, but it would fit within the
framework.

sv once (process) ; sv start (process).
Received on Tue Oct 21 2014 - 00:02:56 UTC