Re: s6/s6-rc policy for Gentoo: XDG Base Directory Specification

[Paul Sopka]

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:



Then:

- Autostart all user-services in an "autostart" bundle the user populated.








This allows 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, ... - 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,... 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.




Do you see any issues with that proposal?


Thank you for your critique!


Paul

3) Being uniform (everything based on s6-tools) and thus (hopefully) relatively easy to maintain.

OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature