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: supervision@list.skarnet.org,
	Laurent Bercot <ska-supervision@skarnet.org>
Subject: Re: Have an external script wait for a oneshot service
Date: Thu, 5 Dec 2024 22:10:17 +0100	[thread overview]
Message-ID: <d7f683c7-b553-4297-91d9-3abe5f5c2c7b@sopka.ch> (raw)
In-Reply-To: <ema78c15a3-12bf-4f58-839a-1240523b1f07@dc4a0aed.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 3861 bytes --]

>>     - 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.)
>
>  Okay. My point is, why do you need that "default" bundle here? Why do
> you want an s6-rc infrastructure active when the user isn't logged in?
>
>  I can understand a permanent supervision tree per user, but a permanent
> service set that includes oneshots feels overengineered to me. What
> problem is this supposed to solve?
>
>
>> - 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.
>
>  My advice is to do your whole 2c point at login time. The script L can
> perform XDG stuff, s6-rc-init, and s6-rc start default. On last logout,
> you stop everything with "s6-rc -da change" and you delete the livedir.
> Only the supervision tree remains, maintaining whatever services the
> user has manually added.
>
>  I don't think there is a good argument for keeping state (which is
> what oneshots do) in user services when the user is logged out. Feel
> free to give counterexamples though.
>
> -- 
>  Laurent
>
I find two problems with this:

- A     Users might want to achieve a state of the user-tree on boot, 
which is impossible without s6-rc
           Though I have to admit that I can not find concrete examples 
of application.

- B     Imagine the following scenario:

           A user wants to run a script every day at 12:00 and sets up a 
snooze user-longrun for that,
           which he installs and starts using s6-rc-init and s6-rc 
respectively while logged in,
           but logically does not stop on logout.
           Now the server reboots, brings up the user-tree again, but 
without the snooze user-service of course.
           The system-longrun 1a/2a would thus need an additional 
mechanism to copy s6 service definitions
           from a user writable directory to the user's service directory.

           This solution has the following implications:

            - B1    The user needs to, additionally to s6-rc source 
definitions, learn s6 service definitions.

            - B2    Distribution maintainers would need to redundantly 
create
                       both s6-rc source definitions and s6 service 
definitions for services,
                       so that users can use the latter at boot time.

All in all this would make things more complicated,
in that users have to learn and consider more things while distribution 
maintainers have more work.

Additionally having s6-rc available sometimes (while logged in) and 
sometimes not (while logged out)
will ultimately lead to confusion.

So while I agree to you, that until I find a concrete examples for A,
s6-rc during "non-login" time is technically not necessary,
lacking it makes many things more inconvenient, complex and inconsistent.

On the other side, why not have it? It is a feature that is probably 
going be useful at some point and comes with little to no cost.

Finally, I want to say that I really admire you being very conservative 
on adding features,
it is great to know that s6/s6-rc will stay sleek and efficient.

Have a nice evening

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 21:10 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
2024-12-05 19:44                 ` Re[2]: " Laurent Bercot
2024-12-05 21:10                   ` Paul Sopka [this message]
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=d7f683c7-b553-4297-91d9-3abe5f5c2c7b@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).