Paul Sopka schrob:
> 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?
That part seems confused. The user is able to control their services by
logging in and then invoking s6-whatever.
> Do you see any cases where this would actually be useful in real world
> applications?
Replacing crond with snooze, for example.
And personally, I want my ssh-agent to stay alive when I log out, so
that the key is still unlocked if/when I immediately log in again.
> 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.
This sounds unnecessarily complicated. Why not simply test for existence
of a well-known entry point somewhere in $HOME and let that set up the
user supervision tree however it sees fit (or not at all)?
> 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.)
Ugh. I hate this thinking. Server/Desktop is not a binary choice. I
regularly ssh into otheruser_at_localhost on my main machine. Sometimes I
log in as otheruser and startx. Occasionally I start a vnc server as
otheruser. I have an mpd instance that runs as its own user.
Any desktop-only solution where people argue "you shouldn't do this on a
server" is one where I'll argue "you shouldn't do this at all".
> [...]
> 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, ...
You can supervise it, but the supervision tree is dependent on the
compositor. If the compositor goes away, the supervision tree needs to
die as well. If you start two compositors, you need to create two
supervision trees, one for each WAYLAND_DISPLAY.
> 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?
* create a unique live dir from the "graphical" template
* start compositor
** in compositor's autostart, have something that exports the
WAYLAND_DISPLAY and calls s6-rc start
** (if possible) register s6-rc stop as an exit hook with compositor
* once the compositor exits, tear down everything.
Or just use X11, which properly separates Xserver from WM, avoiding any
problems caused by uncooperative compositors. <scnr>
> 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.
If it needs a display, it goes into C, otherwise into B.
> 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?
Feasible, sure. Good idea, probably not. A misconfigured compositor
restarting over and over again is a pain to fix.
> 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?
PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the
dbus.
regards,
Jan
Received on Mon Jul 08 2024 - 09:16:00 CEST