Re: Have an external script wait for a oneshot service

Paul Sopka <[email protected]> Thu, 5 Dec 2024 14:52:42 +0100
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
On 05.12.24 09:05, Laurent Bercot wrote:
>
>> To be more precise, I have the following setup:
>> - A longrun L setting up s6-svscan for a user-service-tree.
>>
>> - A oneshot O setting up "s6-rc-init" and "s6-rc start default".
>>
>> (two allow users to have services running on boot without login)
>>
>> - A script run on login (bee it by PAM, .profile or another way),
>>   that starts user services only useful after login, e.g. pipewire.
>>
>> Now of course the script should only be ran after the the 
>> "s6-rc-init" oneshot.
>
>  I get the feeling there's an XY problem here, or some confusion (but
> maybe just in my own brain) because user services are an underspecified
> concept. Can you please describe the details of your setup: at what
> time do you want to start up a supervision tree and an s6-rc-init
> process for a given user?
>  - at boot time? if so, how do you decide what users to start a
> tree for?
>  - at login time? if so, you have a script that you run at login time,
> I don't see the problem here: start the tree and the s6-rc-init in that
> script, not as a part of a set of s6-rc services.
>
> -- 
>  Laurent
>
After the discussions about user services conducted here a couple of 
months ago,
I came to the conclusion that the following would be the best solution:

- All user-trees are started at boot time.

- The user-trees are be prepared in two ways:

     1    One system-longrun service per user:
     - 1a     Have the admin create one system-longrun running 
"s6-svscan" per user (e.g. automated via a script).
     - 1b     Have the admin create one system-oneshot per user to:
         - 1bi     Prepare the live directory for the user-tree 
(preferably under /run/user/${USER}).
         - 1bii     Start "s6-rc-init" and "s6-rc start default".

     2    One instantiated system-longrun for all users:
     - 2a    Have a system-longrun which is an instantiated "s6-svscan", 
with one instance per user
               and a (root controlled) config C specifying which users 
to instantiate for.
     - 2b    This config C shall then be parsed by an additional 
system-oneshot to do the actual instantiation.
     - 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.)

- 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.

- Upon last logout, meaning the logout that causes no logged in sessions 
for the user to be left,
   the script invokes "s6-rc -pu change default" to stop all the login 
services.

This has the following advantages:

- A user can have always running user services (e.g. snooze based timed 
services, calculations, ...)
   no matter whether the user is logged in.

- Services only required during login (e.g. pipewire, mpd, ...) only run 
when the user is logged in.

- Who gets to have a user-tree is decided by root creating the 
user-services as in 1 or instantiation config C as in 2,
   which feels natural, since root also decides who gets a user account 
in the first place.

And the following implications:

- The login script needs to wait for "s6-lrc-init" to be finished before 
it can call "s6-rc start login".
   It hence needs to wait for the corresponding system-oneshot 1b/2c.

Which (as far as I have found) can be solved in one of the following ways:

- S1    Script s6-fifodir functionality in bot the system-oneshot 1b/2c 
and the script L.

- S2    Add a readiness api for s6-rc oneshots like s6 longruns have and 
wait for that of system-oneshot 1b/2c in the script.

- S3    Have the script L do the same as system-oneshot 1b/2c:
         - 1bi/2ci    Prepare the live directory for the user-tree 
(preferably under /run/user/${USER}).
         - 1bii/2cii    Start "s6-rc-init -b" and "s6-rc start login".
   Utilizing blocking locks and tests to work parallel to system-oneshot 
1b/2c.
   This can only be done if the script is ran through PAM, since 1bi/2ci 
requires root privileges.

Since I find solution S2 to be the most elegant,
I wanted to ask whether you are willing to add a proper readiness api to 
oneshots too.
This would generally be a nice addition, as I am sure there are other 
applications to this feature
I can currently not imagine.
Further, I argue that it would make the system more consistent, since 
longruns have this functionality too.

Regards

Paul
OpenPGP_0x71C7C85A2EA30F62.asc (application/pgp-keys, 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)