>> - 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
>
I find two problems with this:
- A Users might want to achieve a state of the user-tree on boot,
which is impossible without s6-rc
Though I have to admit that I can not find concrete examples
of application.
- B Imagine the following scenario:
A user wants to run a script every day at 12:00 and sets up a
snooze user-longrun for that,
which he installs and starts using s6-rc-init and s6-rc
respectively while logged in,
but logically does not stop on logout.
Now the server reboots, brings up the user-tree again, but
without the snooze user-service of course.
The system-longrun 1a/2a would thus need an additional
mechanism to copy s6 service definitions
from a user writable directory to the user's service directory.
This solution has the following implications:
- B1 The user needs to, additionally to s6-rc source
definitions, learn s6 service definitions.
- B2 Distribution maintainers would need to redundantly
create
both s6-rc source definitions and s6 service
definitions for services,
so that users can use the latter at boot time.
All in all this would make things more complicated,
in that users have to learn and consider more things while distribution
maintainers have more work.
Additionally having s6-rc available sometimes (while logged in) and
sometimes not (while logged out)
will ultimately lead to confusion.
So while I agree to you, that until I find a concrete examples for A,
s6-rc during "non-login" time is technically not necessary,
lacking it makes many things more inconvenient, complex and inconsistent.
On the other side, why not have it? It is a feature that is probably
going be useful at some point and comes with little to no cost.
Finally, I want to say that I really admire you being very conservative
on adding features,
it is great to know that s6/s6-rc will stay sleek and efficient.
Have a nice evening
Paul
Received on Thu Dec 05 2024 - 22:10:17 CET