Re: Have an external script wait for a oneshot service

Paul Sopka <[email protected]> Thu, 5 Dec 2024 22:10:17 +0100
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
>>     - 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
OpenPGP_0x71C7C85A2EA30F62.asc (application/pgp-keys, 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)