- 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
