Some first time user questions but not specifically about s6-frontend.
My first question concerns importas. For instance, my network script
contains lines like:
if{ ip addr add 192.168.0.2/8 dev eth0}
whereas most example scripts I see do:
{importas -i ETH0_IP4 ETH0_IP}
if{ifconfig eth0 ${ETH0_IP4 etc..}
Small detail here. If you're using execline, keep the curly braces
surrounded with whitespace: if { ip addr ... }
execlineb won't parse your script correctly if the curly braces
aren't separated from other words.
Does the use of 'importas' mean that you could edit a config file to
change some parameters without having to recompile the datadase?
Yes, that's the point. In the example script, you can see something
above the importas lines like "s6-envdir /etc/env-network"
That means that /etc/env-network is an envdir where you can store the
values for e.g. the IP adresses:
echo 192.168.0.2 > /etc/env-network/ETH0_IP4
and they will be imported in your script. So you get some
configurability there without needing to modify the script.
It's similar to the separation between /etc/init.d and /etc/conf.d
that OpenRC does. /etc/conf.d hosts the policy and is meant to be
editable by admins; /etc/init.d hosts the mechanism, and is not.
The separation isn't as obvious with s6-style run scripts, and it
takes some extra boilerplate effort to cleanly separate mechanism
from policy, in the same way that it takes some extra effort to put
various pieces into appropriate directories (see below for more on
that). That is what I call "emerging good practices": over the years
we have learned that such a separation was a good thing.
The tooling I've been writing lately, and more is to come, is meant
to provide more rails to help people implement these good practices.
Despite my lack of understanding, s6-supervision seems to have been
achieved but only for those processes started as part of the 'boot'
process. The only other 'long running' programs I need are a window
manager (dwm), terminal (st), dbus, a browser, a mail program and a
file manager, all started in .xinitrc and all running in the foreground
(except bdus).
Other people have answered this better than I can, but from what
you're saying, these are all programs launched at X start time, under
your uid, and only alive for the time of your X session. They're all
short-lived programs, as in, they're not supposed to live *forever*,
even if in practice they live very long. Strictly speaking, short-lived
programs shouldn't be supervised; but at the session level the
distinction becomes blurry, and some of what you want falls into the
category of "user services".
User services are a whole can of worms because they interact with a
lot of unsavory interfaces and an ecosystem that is pretty hostile to
policies it does not have full control over. I intend to study the
domain and make it easier for people to run user services with s6, but
that will not be in the short term.
One final question. My service directories are, of course, under /etc,
with all the other s6 stuff. What makes that the worst possible place
for them to be!
So, this is not on you, and this is not even on Debian or similar
distributions that put service directories under /etc.
This comes down to the concept of service directories, which is
close to 30 years old and showing its age. When it was created, in
daemontools, it was meant to be a generic place to store *everything*
about a service. Which was fine at the time, but nowadays distributions,
and semantically conscious users more generally, want to separate files
of a separate nature:
1. service mechanism: read-only at run time, never modified
example: foo/run
2. service configuration: read-only at run time, modifiable by admin
example: foo/rules.cdb (for s6-tcpserver-access)
3. supervisor configuration: arguably the same as service mechanism
example: foo/notification-fd
4. supervisor run-time information: writable at run-time, can be on
a tmpfs
example: foo/supervise/*
5. persistent run-time information: writable at run-time, cannot be on
a tmpfs
example: logs. ISTR some daemontools setups using foo/log, the
service directory for a logger, as a logdir for multilog as well. There
may even be runit service directories still doing that to this day.
6. other categories?
In ideal FHS terms, 1. would go under /usr, 2. would go under /etc, 3.
would go under /usr or /etc, 4. would go under /run, 5. would go under
/var or similar.
As you can see, a service directory is a big bag of stuff with various
lifetimes and various modifiability scales, and maps pretty badly to
a modern filesystem organization.
I still find the service directory model practical from the
supervisor's
point of view, but in order to play nicely with other software, we need
practices that don't blatantly infringe on a filesystem's semantics.
And putting a whole service directory under /etc means that
/etc/sv/foo/supervise will host run-time data with high variability,
and a control pipe for s6-svc, which is definitely not what /etc is
meant for.
I've tried to make things a little better with s6-rc, where the
compiled database, which contains all the read-only parts of service
directories, resides under /etc, but the scandir itself is under /run
and the livedir, also under /run, *copies* service directories so
that live services are all under /run, like /run/service/foo, and
no operation on live ever modifies the compiled database.
It's not perfect because files in the service directory are duplicated.
It could be theoretically improved by making symlinks to the compiled
database for RO files like foo/run or foo/notification-fd, but in
practice most service files are small and the change would add a lot of
complexity for probably very little gain.
A reasonable compromise, if you want maximum simplicity, is to have
your service directories under /var. It's persistent data, but it's
also guaranteed to be read-write and it can host frequently modified
files. It's not ideal to have theoretically static data like foo/run
under /var, but it's certainly better than having foo/supervise under
/etc.
I don't have an entirely satisfying solution yet. I have thought about
revamping the service directory model entirely, but exploding service
data into a lot of various places is not good either. It makes the
supervisor more complex and more brittle, it embeds more policy into
it, and it also makes it harder for the user to troubleshoot potential
problems.
My current line of thought is that it should be solved by automation;
a higher-level configuration interface would take a service file written
(and readable) by a user, and the s6 backend would automatically output
a service directory made of symlinks pointing to data hosted under the
right places. I might work on something like that in a relatively near
future.
--
Laurent
