Hey, thank you for your detailed answer!
> A. a permanent supervision tree, belonging to a normal user, that runs
> services as the user, independent from whether the user is logged in.
Wouldn't anything this does be solved by just dropping privileges of the
corresponding daemons in their startup scripts? That would mean that it
is just a needless complication. Anyway, this is the workaround I am
using on my machine right now xD.
> B. A supervision tree that starts with the first login and ends with
> the last logout. This appears to be what you're working on.
Yes.
> C. A supervision tree that is tied to a graphical session on one seat.
> That would exclude remote logins via ssh. This seems to be what the
> Freedesktop people have in mind when they talk about XDG specifications.
This seems like a worse and less flexible version of B to me, I guess
the only reason it is even considered is because the seat daemon does
all the tracking work for you. Option B does all this does and more if I
understand you correctly, thus I think B is straight up the better way.
One might now argue that some processes need e.g. a running wayland
compositor, but this is the exact case "socket activation" solves. Let's
take for example the "foot" terminal
emulator(
https://codeberg.org/dnkl/foot), which can be run as a server
to accept "footclient" terminal emulator instances, saving memory and
startup time. The server can only be startet once a wayland compositor
is up and running. Using "socket activation"(fd-holding) it can be
configured to only be started once the first instance of "footclient" is
invoked, which can only happen once the compositor is up thus solving
this issue completely. This should be applicable to most if not all
software with this limitation.
Does anyone see any other problem arising from B?
> You're not the only one working on s6-rc user services for Gentoo: see
> https://skarnet.org/lists/supervision/3074.html :) You should definitely
> try and coordinate with Alexis! And also with other people who hang
> on the #s6 channel on oftc.net and may have more ideas to share.
Thanks for the intel!
> Generally speaking, when I have a set of environment variables that
> need to be shared between unrelated sets of processes, I put them in
> an envdir, and source the envdir whenever the variables are needed.
> One way or the other, the only reliable data sharing tool you have
> across process trees is the filesystem.
I thought about this, too. And I see two issues to solve:
A) The format, do you suggest a FILENAME=content which seems easier to
handle with execline and other software's(e.g. dbus) ability to write
specific info to an fd which can be redirected to a file? Or do you
think a file containing KEY=value, probably playing more nicely with
bash and other interactive shells?
B) I think I need to make an example to explain this issue properly:
I use Hyprland(
https://hyprland.org/), which I start from an agetty
instance. Hyprland, as any other wayland compositor/DE, sets env's. Most
importantly WAYLAND_DISPLAY. It does not write those to a file. Thus I
would require the user to add a script launch command to Hyprland's
config which launches a script exporting the required(or all?) env's to
a dir. This is unacceptable.
Plan b) Poll the user env and extract on change and write it to the env
dir, but how to extract the env? Polling is bad.
Plan c) use a notification by a seat manager(e.g. seatd) to run a script
that extracts the env and writes it to the env dir, again, how to
extract the env? This is also bad, since this will most likely end up
being seatd specific, or at least bound to a set of supported seat managers.
Does anybody have a better idea?
> I'm not going to write such a program in the s6 suite, because all the
> stuff around PAM and utmp is 1. very Linux-specific and 2. extremely
> brittle and badly/underspecified. At some point, however, I intend to
> take a good look at PAM and brainstorm about a replacement, because the
> current situation is just holding with massive amounts of duct tape, good
> will and headaches, and this makes me fearful for the future.
Thank you for the info, I have the greatest respect for you writing only
UNIX compatible software(if that's how to correctly describe it?). I am
looking forward to your alternative to PAM.
> In any case, be wary of the trap of using XDG_RUNTIME_DIR to host your
> user supervision tree. It *looks* like the ideal place to do so, but
> in case of a desktop session, it's deleted too early and you don't
> have time to properly terminate your services. Other people who have
> experience with running user services on a desktop will talk about this
> better than me.
I will open a separate thread on the XDG Base Directory Specification,
since I consider this an important point. Generally I'd like to use
XDG_RUNTIME_DIR but have it managed by the the s6-rc system service
providing the user service tree. Thus it should be safe.
Any objections to the second point?
Paul
Received on Sat Jul 06 2024 - 00:27:53 CEST