From: Paul Sopka <psopka@sopka.ch>
To: Laurent Bercot <ska-supervision@skarnet.org>,
supervision@list.skarnet.org
Subject: Re: Have an external script wait for a oneshot service
Date: Thu, 5 Dec 2024 14:52:42 +0100 [thread overview]
Message-ID: <3d1391e4-b240-4675-a839-a34c39d474b3@sopka.ch> (raw)
In-Reply-To: <emec06e599-b3f8-4377-93ca-8dacc407184c@7eadbb8a.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 5086 bytes --]
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
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3195 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
next prev parent reply other threads:[~2024-12-05 13:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-04 15:28 Paul Sopka
2024-12-04 15:38 ` Charles Cazabon via supervision
2024-12-04 17:12 ` Paul Sopka
2024-12-04 21:47 ` Hoël Bézier
2024-12-04 20:00 ` Brett Neumeier via supervision
2024-12-04 20:05 ` Paul Sopka
2024-12-04 20:18 ` Brett Neumeier via supervision
2024-12-04 20:59 ` Paul Sopka
2024-12-04 21:58 ` Re[2]: " Laurent Bercot
2024-12-05 5:59 ` Tanuj Bagaria
2024-12-05 6:54 ` Paul Sopka
2024-12-05 8:05 ` Re[2]: " Laurent Bercot
2024-12-05 13:52 ` Paul Sopka [this message]
2024-12-05 19:44 ` Laurent Bercot
2024-12-05 21:10 ` Paul Sopka
2024-12-05 21:42 ` Brett Neumeier via supervision
2024-12-06 5:32 ` Paul Sopka
2024-12-05 23:03 ` Re[2]: " Laurent Bercot
2024-12-06 12:41 ` Paul Sopka
2024-12-06 15:43 ` Re[2]: " Laurent Bercot
2024-12-06 16:11 ` Hoël Bézier
2024-12-06 17:14 ` Paul Sopka
2024-12-07 23:46 ` Jan Braun
2024-12-05 21:24 ` Jan Braun
2024-12-05 23:15 ` Re[2]: " Laurent Bercot
2024-12-04 20:09 ` Tanuj Bagaria
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3d1391e4-b240-4675-a839-a34c39d474b3@sopka.ch \
--to=psopka@sopka.ch \
--cc=ska-supervision@skarnet.org \
--cc=supervision@list.skarnet.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).