I know what you mean, and technically and in theory I fully agree with you. As mentioned this is my currently running workaround until I implement Turnstile.No, because the point is to allow users to have their own services, and you definitely don't want them to have access to the root supervision tree. So you basically have to have a separate subtree for each user (a privilege-dropped s6-svscan), and there are a few more policy questions to answer, in particular how to make sure the users cannot flood the root logs by misconfiguring their own logging system. It's doable, but not quite obvious, and it's also not quite obvious how to set up the system so that you don't spawn a supervision tree for inactive users or users who don't use the feature. So there's a littlemore work involved.
My claim was more about a practical, applied scenario. In the terms of: If a user is not logged in, he simply cannot control his services. So why shall he have an entire user supervision tree of which the sole purpose is to allow the user to control the services running with his permission set, running at a time he is not logged in, thus not able to control his services?
I am sure there are niche cases this solves, but I do not think they are worth the overhead/maintenance burden of adding this on top of B).
Do you see any cases where this would actually be useful in real world applications?
I solved that by simple read/write permissions on on the root log dir, if you mean that.in particular how to make sure the users cannot flood the root logs by misconfiguring their own logging system.
If you are talking about flooding the uncaught logs logger of the system. Is this not just solved by a s6-log service attached to the user s6-svscan, acting as a catch all logger for the user tree. Since this is inherently a system service, the user does not have the power to sabotage this.
I am not sure whether I got you right on that.Concerning your last point, the best I can offer for now is to have a script, using a template dir to create the user supervision system service. This can of course only be done by the system admin. The user can then add whatever he wants to a previously empty bundle described in the wiki, before invoking an "s6-user-db-update" command or similar, invoking a script that I supply and that does the compilation and s6-rc-update command.
B) shall solve the issue of not spawning needless supervision trees, since it only spawns them upon login.
I, again, technically agree fully, but this is in my opinion already solving itself in practice: on a desktop system you rarely have someone ssh'ing in. On a server system no user will ever add heavy desktop scripts to the user service autostart, because a) he can't use them anyway and b) they shouldn't be there(why the heck should the sysadmin install e.g. pipewire or mpd on such a server? Packages which would be responsible for drawing in the required user services.)It really depends on your objective. B makes a lot of sense if you want to treat remote logins the same way as seated logins, but there is also an argument to have remote logins be as simple as possible while not minding deploying the red carpet and a whole lot of extra services for seated logins, where the overhead of setting everything up will be negligible compared to the desktop stuff anyway.
If you are actually talking about setting up s6-svscan etc., I think that a) your software and solutions resource consumption is negligible on modern hardware, b) I would consider user services to be a more desktop centric system anyway.
B is entirely legit if you make it clear that's what users get. Just tomake sure users don't run xeyes when logging in remotely.
lmao
The format doesn't matter if you control the readers. s6-envdir reads envdirs, envfile reads key=value shell-like files. Choose whatever format works best for you; if you need the variables to be read from a shell as well, the envfile format will work best. It's a question ofconvenience and preference, really.
This is why I am asking all the (more experienced) people on this list. So that I make the best and most informed decision.
Since the only purpose is to synchronize interactive shells like bash/zsh/..., this is probably the deciding point:
if you need the variables to be read from a shell as well, the envfile format will work best.
Apologies, I did not explain that well. It basically goes hand in hand with what I have written here:That means WAYLAND_DISPLAY, by design, is only be accessible to processes that descend from Hyprland. Why do you need to subvert it sounrelated processes can access it?
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.
And by "up and running" I mean WAYLAND_DISPLAY is set by the compositor.I would not call the foot terminal emulator unrelated to WAYLAND_DISPLAY and the compositor at all.
But I argue that, in case it is ran in it's server configuration, it makes sense to supervise it, i.e. not starting it directly from the compositor. The same can be said about notification daemons, status bars, ...
As you have already said this is the best example for why an additional C) would make sense. This is where my next problem arises, imagine we now set up another supervision tree for starting it up as soon as the compositor is there.
I can probably cleanly do this my reading from the socket seatd provides and using s6-fdholder-retrieve, right? How could this be stopped cleanly upon exiting the wayland compositor?
The issue on how to retrieve WAYLAND_DISPLAY arises again.This could be solved by starting the "graphical" s6-svscan from the compositor, e.g. Hyprland, even though the compositor is not supervised, once it crashes it takes everything depending on it down with it anyway, so this doesn't matter. The biggest issue is, yet again, how to stop the services cleanly on exiting the compositor. Any ideas?
Another issue I see is that the user of the desktop system gets a third supervision tree he has to manage. And for most of the more casual people it is probably hard to correctly understand and use the differences between C) and B), in the little free time they can invest into linux.
This is why I looked at the idea of "socket activation", but now that I think of it, this will probably fail for notification daemons, status bars, etc.
Anyhow, you have convinced me, the third supervision is the most elegant and clean option. I am yet again thankful for your detailed answer. I have learned a lot and you made me aware of issues I did not see, but have to solve.
There is another alternative I see: starting the compositor itself as a user service. I have to think about how feasible this is. What do you think?
This brings me to the final problem which the alternative mentioned above solves already: The user services manage a couple of things, namely the XDG_RUNTIME_DIR and DBUS_SESSION_BUS_ADDRESS that need to be propagated to the users login shell. Is there a more elegant way to do this other then having the user source an env directory in his .bash_profile?
I will not :D. I will settle with Turnstile for now (testing it today evening), but I will happily replace it once your future solution is finished. Your software appears perfect to me.Don't hold your breath - this is a longterm plan, and a considerableamount of work.
Thank you! Paul
OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
