Re: First time user experiences

On Thu, 26 Feb 2026 11:29:10 +0000
"Laurent Bercot" <[email protected]> wrote:

> >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
> 

Thanks all for the helpful replies. They have cleared up a number of
issues.

I am just starting a new LFS build using S6 as boot; a good opportunity
to rearrange some directories.

Ian