> - 2c A third system-oneshot does:
> - 2ci Prepare the live directory for the user-tree for each user specified in config C (preferably under /run/user/${USER}).
> - 2cii Run "s6-rc-init" and "s6-rc start default" for each user specified in config C.
> (this can be merged with the instantiation system-oneshot if desired.)
Okay. My point is, why do you need that "default" bundle here? Why do
you want an s6-rc infrastructure active when the user isn't logged in?
I can understand a permanent supervision tree per user, but a permanent
service set that includes oneshots feels overengineered to me. What
problem is this supposed to solve?
>- Upon login, a login script L shall invoke an "s6-rc start login" with ("login" being a bundle) for the user logging in.
> (this can be further extended using PAM to run "s6-rc start ${PAM_TYPE}" to differentiate different types of logins)
> The script L can be started by PAM, .profile or in some other way.
My advice is to do your whole 2c point at login time. The script L can
perform XDG stuff, s6-rc-init, and s6-rc start default. On last logout,
you stop everything with "s6-rc -da change" and you delete the livedir.
Only the supervision tree remains, maintaining whatever services the
user has manually added.
I don't think there is a good argument for keeping state (which is
what oneshots do) in user services when the user is logged out. Feel
free to give counterexamples though.
--
Laurent
Received on Thu Dec 05 2024 - 20:44:17 CET