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 autostartIn 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).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.(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).
Paul
OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
