> 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.
You have convinced me, I will see whether it is feasible to have a
*third* user-service tree. I fear I just have to bite the bullet and
decide upon one or two options or at least let the sysadmin decide. Yet
another reason to not integrate extremely tight into Turnstile and
similar, which would disallow this flexibility.
An alternative would be two main bundles per user service tree, that
itself always starts on boot:
One to start at boot time.
Another one to start on first login and stop on last login.
This seems the most elegant and efficient. Am I overlooking anything?
> 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)?
If I understand correctly, this would only be possible using
instantiated services, I like the idea and I am looking into this.
> 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".
It looks like I just do not have enough experience, that's why I am
asking you all on those points. You are right.
Using the idea I stated above, one could use different PAM modules to
start different bundles tho, e.g. an ssh bundle on ssh login, a getty
bundle on getty login, a greetd bundle on greetd login.
> * 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.
Yes, I have suggested this too, the issues is not the starting part, but
the proper stopping of the services. This can only be guaranteed if the
compositor sends SIGTERM to s6-svscan upon exiting. I still need to test
that, but to not have to rely on the compositor doing that correctly is
why I have proposed hooking into seatd in the first place.
The finish script of the s6-svscan should then handle cleanup just fine.
> Or just use X11, which properly separates Xserver from WM, avoiding any
> problems caused by uncooperative compositors. <scnr>
I am planning to support an entire distro, thus I need to support them
all: well behaved compositors, badly behaved compositors, X11, ...
> If it needs a display, it goes into C, otherwise into B.
I guess writing this into a wiki article mandatory for user services
anyway would be good enough.
> Feasible, sure. Good idea, probably not. A misconfigured compositor
> restarting over and over again is a pain to fix.
Agreed.
> PAM. Assuming you use PAM to create the XDG_RUNTIME_DIR and start the
> dbus.
Using PAM for propagating the env's seems reasonable, since we are using
it already anyway. Will test.
On a sidenote, I still think creating XDG_RUNTIME_DIR should be the job
of the system-service managing the user tree.
Thank you for your input!
Paul
Received on Mon Jul 08 2024 - 11:03:47 CEST