Re: s6/s6-rc policy for Gentoo

[Paul Sopka]

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:



B) I think I need to make an example to explain this issue properly:

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? 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.

Does anybody have a better idea?

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.

 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

OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature