On 9/24/2015 2:47 AM, Laurent Bercot wrote:
On 24/09/2015 04:54, Avery Payne wrote:
1. Copy the entire contents of the svcdef/ directory into the s6
source definition directory, including dot file support directories.
There is no room in the source definition directory for a support
directory as svcdef/ ; I mean, you can put it anywhere, but
s6-rc-compile won't know what to do with it, and won't include it
in the compiled database.
That's why I said to copy the contents, not the directory. ;) The
contents of svcdef is, in purpose, the same as the source directory, but
it's not in the right format for s6-rc, which is why I need all of the
steps in the prior message. If the steps are followed by running the
soon-to-be-written "use-s6-rc" script, then the result will be a
complete conversion to the appropriate format that s6-rc requires to
compile the definitions, including support for dependencies.
I am still thinking about if logging should be allowed to "break" so
they can piecemeal their own solution, or if I should "automagically"
create logging definitions in the source directory that are s6-rc compliant.
If your created services need to reference things in a global
support directory, the best practice is to install this support
directory into an official location, and to use the absolute path
to this location in your scripts.
This is a problem, as the entire set of definitions are meant to use
relative paths, so that they can be relocated just about anywhere
without requiring a bunch of "de-referencing" during the install
process. More on this in a moment.
s6-rc-compile will only treat
local data: if you have global data, you're in charge of it.
The only data that may be an issue is the assignment of user accounts
other than root. This is Yet Another Problem(tm) that I've been mulling
over and I haven't found a satisfactory answer that would be portable
between various platforms. This would eventually manifest itself as a
small text database along with a single script to set user/group
definitions. The script would (in theory) reset the meaning of T_UID
and T_GID in all of the env/ directories of each definition, so that
your run-time accounts match the accounts used by your distribution.
2. Use the install command to copy .bin, .finish, .log, and .run from
the source definition directory into the compiled definition
directory.
I would highly recommend NOT messing with the compiled database
after it has been created. The format isn't fixed, and I want to
have complete freedom to change it.
This is probably the only real problem in the arrangement I'm using
then. The entire premise is "the support scripts live where the
definitions live and are called with relative pathing, allowing the
definitions to be located anywhere". This was done precisely to avoid
the mess of "you MUST have your scripts/support scripts live at this
exact path", which was originally inspired by a message exchange we had
months ago about separating policy from mechanism. For my definitions to
work, those four dot-directories have to live where the run-time
definitions live. In this case, your compiled directory is the
equivalent of a run-time directory.
I am certainly not adverse to changing their names or locations - the
entire purpose is to have a set of definitions that work out of the box,
and I need to make it do whatever is required to achieve that - but I
cringe at the concept that I would need to use an absolute path, because
I'll end up making everything brittle as a result. I'm open to
suggestions on how to fix this.
The only official interface
is the source format; you should do whatever is required to
whip up a working source definition directory that doesn't need
extra magic after the compilation phase.
The only magic needed is that the support directories have to be located
in the same runtime location, so that the relative path links will align
and everything will be found. The compiled definitions are the
equivalent of a runtime location, therefore, they must live there.
Once you have run
s6-rc-compile, the database is opaque stuff you can't modify;
you can move the compiled directory around, but don't mess with it.
I don't. None of the definitions write files or data into themselves at
runtime. The only thing that changes is the symlinks that are used, and
if you look at the instructions I gave, that step is performed in the
source, not the compiled. (Ok, yes, I create some files in the *source*
directory, but that's necessary to support s6-rc and currently acceptable)
Also, when I said that s6-rc-compile does not dereference symlinks,
I partially lied. It is true for whatever is in data/ and env/
subdirectories.
The issue I am trying to work around with the dereference in step (7) is
that the env/ in my definitions is not a real directory. It is a soft
link pointing to a directory inside another directory that is in the
same location. Example:
myservice/env -> ./version/1.0.0
myservice/version/0.8.0
myservice/version/0.9.0
myservice/version/1.0.0rc
myservice/version/1.0.0
In this example, prior settings for versions 0.8.0 through release
candidate 1.0.0 are retained should the sysadmin desire to "roll back"
myservice to a prior version. In my instructions, I'm simply moving the
contents of /version to /data and retaining the same structure, so you
would see this in your source directory:
myservice/env -> ./data/1.0.0
myservice/version/0.8.0
myservice/version/0.9.0
myservice/version/1.0.0rc
myservice/version/1.0.0
myservice/data/0.8.0
myservice/data/0.9.0
myservice/data/1.0.0rc
myservice/data/1.0.0
...and of course, s6-rc-compile would ignore /version and move only the
contents of /data. So all that leaves is that /env needs either (a)
stay a symlink pointing to a directory in /data, in this case the
directory is named /data/1.0.0 or (b) dereference /env entirely, turning
/env into a real directory filled with the contents of the files in
data/1.0.0 so that the files are retained. Either solution works.
But "special" scripts that make a service directory
such as ./run and ./finish are definitely not copied verbatim; those
links will be dereferenced. You cannot assume that your run scripts
themselves are called ./run, either: in some cases, s6-rc-compile
puts a wrapper around them.
It doesn't matter if they have a wrapper, as long as the terminus of
that chain ends up calling ../.run/run at some point. The ../.run/run
is (again) not a real file, it's a symlink pointing to the real run
script, which (as you have guessed) lives in ../.run . I did this so you
could literally switch the entire system to use a new launcher by
changing a single link. It's how I was able to provide execline support
without writing a separate file meant for execline in each and every
definition; you would create the appropriate execline script as
.run/run.execline , then change .run/run to point to .run/run.execline,
and you're done. Right now, .run/run points at .run/run.sh , which is
the ash/dash/bash based launcher.
If you need to perform run-time magic, put all your stuff in data/
and operate there.
Which is fine. That is why I had step (7), which converts my version/
directory into a data/ directory. If env/ is copied as-is by
s6-rc-compile, the result of those conversion steps will have env/ as a
symlink pointing to data/(some version number) which is the desired result.
But as much as possible, the magic should happen
when you convert scripts to the s6-rc-compile source format, so the
compiled database remains simple and straightforward.
That's what I was trying to achieve. The only issue I have left is
trying to get support for .run/ and friends, which have to be "called"
by a relative symlink that points to ../.run/run (see above). One of
the stated goals of the project is that there will be no such thing as a
separate /run file in each definition (although I have a few stragglers
I have to clean up); instead there is only the one run script which I
happen to furnish, and you can change that one script to Whatever Your
Heart Desires, and everything just works.
