Re: s6/s6-rc policy for Gentoo

Paul Sopka <[email protected]> Sat, 6 Jul 2024 01:03:09 +0200
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
Thanks for your input!

> As Mobin said, Turnstile from Chimera Linux answers this problem, and 
> also manages the XDG_RUNTIME_DIR folder.
> Since it actually has hooks to coordinate with the supervisor (unlike 
> elogind, where the systemd-specific code for that in logind is just 
> stubbed out), it makes XDG_RUNTIME_DIR safe to use. All that's needed 
> is a s6-rc-aware backend. I'd write one, but haven't yet because I 
> already have user services set up using Laurent's approach A (i.e. a 
> user service tree that's always up regardless of login) and the fact 
> that s6-rc uses a compiled database introduces some questions existing 
> backends have no answer for (Should the the database be compiled upon 
> login? Should the backend come with a wrapper around s6-rc-compile 
> aware of turnstile's settings? etc.).

I am looking at Turnstile, it indeed appears to be the right tool for 
the job, until Bercot develops an alternative to PAM.

> Since it actually has hooks to coordinate with the supervisor (unlike 
> elogind, where the systemd-specific code for that in logind is just 
> stubbed out), it makes XDG_RUNTIME_DIR safe to use.

I am planning to manage XDG_RUNTIME_DIR with s6-rc, since I am planning 
to have it hold the livedir. Even though Turnstile is looking like a 
safe option here, I want to delegate as few critical operation as 
possible to external tools, so I can easily replace e.g. Turnstile with 
a future, improved solution. I am not yet sure whether this is the best 
approach, but up until now it does seem like that. Any critique is welcome!

> All that's needed is a s6-rc-aware backend. I'd write one, but haven't 
> yet because I already have user services set up using Laurent's 
> approach A (i.e. a user service tree that's always up regardless of login)

Regarding A), see my answer here: 
https://skarnet.org/lists/supervision/3116.html. Additionally, I'd like 
to mention that A) is the most efficient and simple solution on a single 
user system, but by no means an elegant one. Also it will will fail on a 
multi-user system, especially considering resource consumption.

I will soon test Turnstile and write a backend. If it works well, it 
will be in the repo and I am looking forward to improvements to it!


> and the fact that s6-rc uses a compiled database introduces some 
> questions existing backends have no answer for (Should the the 
> database be compiled upon login? Should the backend come with a 
> wrapper around s6-rc-compile aware of turnstile's settings? etc.).
I do not think that the backend should be involved in any compilation of 
the db. I see two ways the db/source dir changes:

A) The user adds a custom service / adds any service to autostart

In this case it is also up to the user (with an automation script 
turning it into one command) to compile and update the s6-rc-db.

B) The package manager installs software that includes a script.

In that case it is up to the package manager to invoke the script 
compile and update the s6-rc-db so the user can just start it using the 
usual commands.

A possible alternative would be a system service monitoring all source 
dirs and recompiling on change. This would exchange user control as well 
as resource usage for ease of use, which I generally do not like.


> The approach I use on my machine is prepending the runscripts with 
> `s6-envdir ../../../env` (assuming there's an env folder besides 
> s6-rc's live dir), and touching/writing files there. I don't find this 
> fundamentally inelegant; it follows the general "the filesystem is the 
> database" principle, and avoids introducing an IPC endpoint in the 
> supervisor.
I can't argue with your claim about elegance, I would consider it 
elegant. See https://skarnet.org/lists/supervision/3116.html for the 
issues I see with this.


> Read http://jdebp.uk/Softwares/nosh/avoid-dbus-bus-activation.html if 
> you're writing services for D-Bus stuff (like elogind/bluetoothd).
>
> (Yes, s6-rc isn't well suited for dynamic events yet, so the second 
> approach of replacing the activation program is ugly, but plenty of 
> bug reports in the Artix Linux forum are related to this — I don't 
> know why they haven't disabled it yet).
Thanks for the heads up, will definitely read! To be honest, I did not 
know dbus even had such capabilities and never even considered using 
dbus for such a thing. I rather consider dbus a necessary evil for 
desktop systems. As long as s6-rc does not have dynamic events I will 
simply not try to hack them in. Gentoo users will probably be fine with 
that, since most of them are probably using Open-RC which is way farther 
away from such functionality than s6-rc is.


Paul
OpenPGP_0x71C7C85A2EA30F62.asc (application/pgp-keys, 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)