On Mon, Oct 20, 2014 at 10:52 AM, John Albietz <inthecloud...@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).