Re: Have an external script wait for a oneshot service

[Paul Sopka]

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:

    - 1b     Have the admin create one system-oneshot per user to:

        - 1bii     Start "s6-rc-init" and "s6-rc start default".

    2    One instantiated system-longrun for all users:

    - 2c    A third system-oneshot does:



  The script L can be started by PAM, .profile or in some other way.



This has the following advantages:


  no matter whether the user is logged in.





And the following implications:


  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:





- S3    Have the script L do the same as system-oneshot 1b/2c:

        - 1bii/2cii    Start "s6-rc-init -b" and "s6-rc start login".


Since I find solution S2 to be the most elegant,

I can currently not imagine.


Regards

Paul

    - 1a     Have the admin create one system-longrun running "s6-svscan" per user (e.g. automated via a script).         - 1bi     Prepare the live directory for the user-tree (preferably under /run/user/${USER}).     - 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.         - 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) - 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. - A user can have always running user services (e.g. snooze based timed services, calculations, ...) - 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. - The login script needs to wait for "s6-lrc-init" to be finished before it can call "s6-rc start login". - 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.         - 1bi/2ci    Prepare the live directory for the user-tree (preferably under /run/user/${USER}).   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. 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 Further, I argue that it would make the system more consistent, since longruns have this functionality too.

OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature