Hello,
El jue, 23 abr 2026 a las 14:45, kurth4cker escribió:
>
> I'm using s6 as user daemons and some other long running processes for a while.
> I wanted to have dependency tracking and decided to try s6-rc within user
> services.
> ...
> But I can't understand how to use both s6-rc-install and s6-rc-init
> properly.
I'd like to make some observations about this setup and ask one
question, but let me first paraphrase some of what has been already
said. Currently, there are 3 "levels" (let's call it that) of user
interfaces to s6 + s6-rc:
Lowest level: s6-rc-compile, s6-rc-update, s6-rc-init and s6-rc (to
name the most prominent ones). This is all we had until s6-rc-0.6.0.0
and s6-frontend.
Middle level: The s6-rc-repo-* commands. If you use these directly,
they can take care of running s6-rc-compile and s6-rc-update for you.
You need s6-rc-0.6.0.0 to get them, but not s6-frontend.
Highest level: s6-frontend, a separate package. If you use this, it
can take care of running s6-rc-repo-* and all "lowest level" s6-rc
commands for you, and also some of the s6 ones —and some of the
s6-linux-init ones, but they don't apply to "user services"—.
> $ pstree
> `-s6-svscan scandir
> |-s6-supervise user:tmux-log
> |-s6-supervise user:tmux
> |-s6-supervise user:s6rc-fdholder
> |-s6-supervise user:s6rc-oneshot-runner
> |-s6-supervise river.wayland-0:gammastep-log
> |-s6-supervise river.wayland-0:gammastep
> |-s6-supervise river.wayland-0:beansprout-log
> |-s6-supervise river.wayland-0:beansprout
> |-s6-supervise river.wayland-0:s6rc-fdholder
> |-s6-supervise river.wayland-0:s6rc-oneshot-runner
> |-s6-supervise river.wayland-0:foot
> `-s6-supervise river.wayland-0:foot-log
>
> $ ls -l $XDG_RUNTIME_DIR/s6-rc/
> ...
> live.river.wayland-0:s6-rc-update:S8wv3q
> ...
> live.user:s6-rc-update:TCRft7
> ...
> btw there is my service store for user services:
> https://codeberg.org/kurth4cker/s6-rc-store
First observation: the definitions in your service store don't have a
'dependencies.d' directory, so you are not really handling
dependencies between services yet. You are using one convenience
feature of s6-rc, though: service bundles (with 'river-bundle').
Second observation: this setup has one s6 scan directory, one service
store, but *two* s6-rc live state directories (so, two s6-rc
"instances" so to speak), which has an impact on the management of
your services:
> I have river and user sets in my s6-rc repository.
So, unless there is a better way to do it I haven't thought of, you
either need two repositories, or, as you did it, one repository with
two sets, and, if using s6-frontend to manage the repository, two
different (in non-default places for "user services", so you need the
S6_FRONTEND_CONF environment variable) configuration files. Because
you at least need two different values of the 'livedir' variable when
using 's6' commands. Either that, or one single configuration file but
an explicit -l (--livedir) option for the command when you need to
override the configured value of 'livedir'.
Also worth noting, the 's6 system boot' command (if using s6-frontend)
cannot currently pass a -p option to s6-rc-init with the prefix, so
you wouldn't be able to replicate your current setup exactly.
Therefore, I have to ask: what was your motivation for setting up two
different s6-rc "instances" for your services? Or, rephrasing the
question differently, what is so special about tmux, compared to
beansprout, foot and gammastep? Or is tmux not a "user service" really
(but you are grouping it with those in the same scan directory
anyway)?
> I copied compiled service databases to somewhere else as
> "initial", linked them to "current". Then s6-rc-init and
> s6-rc-set-install for corresponding bootdb's.
>
> Is there a better way? Or should just script around from this manually
> copying approach.
Your setup needs two sets of notable actions:
1) Management of services setup (adding, removing, changing their
definition or their prescription). s6-frontend can help you do that
with the 's6 repository sync', 's6 set' and 's6 live install'
commands. In particular, they would take care of the copying and
linking of the compiled databases described above for you.
2) Starting what has to be started when you log in and the computer
starts River. You need some scripting for this, yes. This means:
2a) Creating the needed scan directory / directories in $XDG_RUNTIME_DIR.
2b) Starting the corresponding s6-svscan processes.
2c) Running s6-rc-init for each needed live state directory when
s6-svscan is ready, and running at least one 's6-rc start' command per
livedir to bring the necessary services up (exactly one command if the
database has conveniently defined service bundles).
s6-frontend can help you do 2c) with the 's6 system boot' command (and
a non-default configuration file), but a "two instance" setup" would
need that command twice with different configuration...
G.
Received on Fri Apr 24 2026 - 19:35:31 CEST