Re: [announce] s6-rc: a s6-based service manager for Unix systems

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Wed, 23 Sep 2015 19:54:50 -0700

On 9/23/2015 5:55 PM, Colin Booth wrote:
> On Wed, Sep 23, 2015 at 3:58 PM, Avery Payne <avery.p.payne_at_gmail.com> wrote:
> I'd suggest seeing about doing a one-time conversion to the
> ./dependencies naming, and then updating your scripts to use that name
> instead of ./needs in order to not break folks who don't use s6-rc.
There's already a set of use-* scripts in svcdef/.bin that re-jigger all
of the command references around, for daemontools, runit, and s6. I've
been debating more of these "use" scripts, so it would assist with
integration into whatever "rc" system is installed. In the case of
s6-rc, there would be a use-s6-rc script, which would do the following:

1. Copy the entire contents of the svcdef/ directory into the s6 source
definition directory, including dot file support directories.

2. Use the install command to copy .bin, .finish, .log, and .run from
the source definition directory into the compiled definition directory.

3. Inside of the compiled definition directory, call the .bin/use-s6
script for obvious reasons. :)

4.In the source definition directory, for every definition, create a
file ./type that contains the word "longrun"

5. In the source definition directory, scan for definitions that have
./needs/ present, and "build" a ./dependencies file. If ./needs/ isn't
present, nothing happens for that definition.

6. Create separate (definition)-log directories that take the place of
the existing ./log/ arrangement, and create the necessary
(definition)/producer-for and (definition)-log/consumer-for files, so
that logging is retained. I suppose I should prompt the user (somehow)
and ask if they want to have per-daemon logging as a default, and if
they answer no, simply let logging "break" by turning this step into a
no-op. As logging uses the same relative pathing and template
arrangement as the ./run file, this isn't too hard, but it's messy.

7. Copy everything inside (definition)/version/ to (definition)/data,
and re-link ./env to point to ./data/version/(whatever)

The resulting source directory should have the correct format, and the
existing linkage will be retained when it is compiled. Using
s6-rc-compile will, if I understand it correctly, move ./run, move
./env, move ./data, move producer-for/consumer-for, ditch ./version, and
ditch the ./log definition for its own pipeline construct. The question
is, will s6-rc-compile move ./env, dereference it, or simply gak at the
concept of moving a symlink? If it moves ./env, that's fine, we're
covered by ./data being created in step (7). If it de-references,
that's actually cool, because you'll always end up with the correct
settings, I can eliminate step (7) completely, and nothing needs to
change. If it gaks, that's a big problem, because the "./env points to
./version/(something)" directory solves some issues that aren't being
addressed elsewhere. Laurent, can you tell me what the behavior will be?

> I can send you my (almost) 100% functional Debian rcS stuff
> replacement stuff that I use to run one of my systems. If you can
> figure out why the acpid keyboard hooks don't work after start, that'd
> be great. Cheers!
I probably misunderstood, or misrepresented what I was after. I thought
that we were talking about something that would take a
/etc/init.d/(whatever) script and churn out the appropriate ./run file.
Received on Thu Sep 24 2015 - 02:54:50 UTC