> You're making more work for yourself and the people who'd help you
> maintain the service set, and making an s6 policy with more
> assumptions.
I disagree. If the most important work is delegated to the service
scripts, once it works, it works. Forever. Easy to adapt and replace by
sysadmins/users.
Extremely relying on specific functionality of an external program,
forces the maintainer to tightly monitor the programs development and
extensively test all its releases, in practice: forcing the possible
Turnstile package on Gentoo to have the same maintainer(maintaining
group) as the possible s6/s6-rc profile. It also forces more assumptions
on everybody, since we need to comply to the exact way Turnstile solves
things:
> Non daemontools-style supervisors, such as dinit (which is Turnstile's
> default), also don't provide a simple "setuidgid" privilege dropper,
> so they'll have little use for this functionality unless they add more
> dependencies or become more error-prone.
This shows it quite nice, as it would have me need to align more to the
limitations of dinit, even though I do have the tools for the job.
Running the backend as root could just be added as a config option to
Turnstile.
But I think we are approaching philosophical/subjective grounds here.
It is good that we develop our own interpretations of "the best"
solution, learning from and criticizing each other.
> There's two additional arguments: "$srv_dir", a folder that's
> dedicated to temporary files for the service manager (which seems to
> me to be the ideal place for s6-svscan's scan directory and s6-rc's
> live folder¹), and "$confdir", which is the path to where the
> configuration files reside (which can serve as the storage place for
> an environment file).
It seems less then ideal to me to use the filesystem as a temporary
storage, when all that is needed are a handful environmental variables,
which can easily be passed to the backend.
> See `/run/service/s6rc-fdholder-filler/run` on your machine for
> another solution: have 'ready' be only
>
> ```
> s6-rc -l "$string" -up change default
> ```
>
> and 'run' be
>
> ```
> ... fdmove -c 3 1 pipeline -dw { if -nt { s6-rc-init } s6-svscanctl -t
> ... } fdswap 3 1 s6-svscan -d3 ...
> ```
>
> Instead of just s6-svscan (i. e. feed the readiness notification to
> another step instead directly sending s6-svscan's notification to
> turnstile).
Thanks, will test!
> Given dinit has the service management and service supervision layers
> in the same executable, Turnstile's authors probably expect the
> service management layer being up and running by the time 'run' has
> notified readiness, which is possibly why they didn't bother exporting
> variables in the "ready" script.
Adding the ability to pass the env's to the ready function in the form
of a config option in turnstile.conf would probably be the best way to
allow elegant integration with s6-rc. I have opened an issue for that,
see here:
https://github.com/chimera-linux/turnstile/issues/15
> Turnstile already answers item b: `/etc/turnstile/backend/*.conf` and
> argument #4 of the run script. For a, nothing stops a backend from
> sourcing one itself, and the runit backend is a precedent.
Yet again needing tight integration with Turnstile. I do not think this
is inherently bad, I just do not personally like such tight integration
if I can do it differently.
> I'd rather document that the user must edit the desktop service
> daemon's settings if they want to tweak how desktop services work.
I technically agree, but some configs must be global, e.g.
${DBUS_SESSION_BUS_ADDRESS}, since other services, e.g. Pipewire, rely
on them.
The alternative would be a dynamically populated and sourced env
directory, I am still thinking about this, but the issue I see is how to
propagate the required (currently ${DBUS_SESSION_BUS_ADDRESS} and
${XDG_RUNTIME_DIR}) to the user's login shell now that they are dynamic
and maybe not completely set on login?
> For instance, I once tried to make my equivalent set of scripts
> "username-agnostic" and use s6's (the supervision suite's) built-in
> instancing feature — with the username as the parameter — to spawn
> user supervision trees. This was enough to make execline painful to
> use correctly, and I had to switch to a shell script.
I will try that too, because I think this would be the most elegant way
to start user service trees, if one doesn't want to rely on Turnstile.
> I'm currently writing a turnstile backend [1] that has a catch-all
> logger and does s6-rc-init in the `run` step; it's refreshing to be
> able to reasonably write it in execline.
>
> [1]https://paste.artixlinux.org/view/6308e776
Wow, I will look into that in more detail for sure!
> I don't think "low number of config files" is a metric worth
> optimizing for, especially when the tradeoff is encoding desktop
> assumptions in low-level policy.
I need to be careful to not have two or more important config files that
contain the same setting parsed by different essential software. This
would require the sysadmin to keep them in sync.
Additionally I do think that "low number of config files" is an
important metric when it comes to /related/ settings, since that makes
life easier for users and sysadmins.
> See s6-svscan's -X option. This can be done entirely within the user's
> supervision tree, and relies on the same foundation as the catch-all
> logging in s6-linux-init; it just requires the scan directory to be
> initialized with a catch-all logger before s6-svscan is run.
Thank you, I will take a look!
> As Laurent said (in regards to graphical user services, but I believe
> this applies here), the tradeoff is introducing environment data
> sharing and process lifetime management across unrelated process
> trees, which is neither.
This might be subjective again, but I would not consider the user (and
thus his service-tree) be unrelated to the system he uses (and thus the
system-tree)
> I'm not aware of any Turnstile replacements, and given your design
> goals, I think you're better off creating a small single-job PAM
> module like pam_rundir [1]. Make it invoke
> s6-rc/s6-instance-{create,delete}/whatever when logging in/out instead
> of managing a runtime directory.
>
> I don't think writing such a module is worth it, though. Turnstile
> allows your system policy to only worry about core machine management;
> your proposal will instead muddle that with stuff that's only relevant
> for the desktop services.
>
> [1]https://gitea.artixlinux.org/artix/pam_rundir
Thanks for the heads up and the link.
This brings me to my last point, an idea I got while writing this:
https://skarnet.org/lists/supervision/3131.html.
The idea is the following:
- Make a user service tree on boot (preferably using instantiated
services) if the user has an appropriate dir in ${XDG_DATA_HOME} (most
likely /home/${USER}/.local/.share/s6-rc/...). This service prepares all
the basics, e.g. ${XDG_RUNTIME_DIR}, the logging dir of the user
services, ...
Then:
- Autostart all user-services in an "autostart" bundle the user populated.
- Upon first login start a "login" bundle the user populated, stop it
after last logout. This can be fine grained with a bundle for ssh login,
a bundle for getty login,..., using appropriate PAM modules.
- An env directory which is also used by the user-services shall be
sourced upon login.
- Upon starting a graphical session start a sub-user-tree with the
s6-svscan process being a child of the wayland compositor,X server,...
This allows the following:
1) Solving all of Bercots cases
(
https://skarnet.org/lists/supervision/3114.html) A), B) and C) with
"just" 2 user-service-trees, one being nested inside the other.
2) Not relying on external tools to do basic work.
3) Being uniform (everything based on s6-tools) and thus (hopefully)
relatively easy to maintain.
Do you see any issues with that proposal?
Thank you for your critique!
Paul
Received on Mon Jul 08 2024 - 14:55:31 CEST