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