supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
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 --]

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