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
Received on Thu Dec 05 2024 - 14:52:42 CET