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
Received on Sat Jul 06 2024 - 01:03:09 CEST