From: "Hoël Bézier" <hoelbezier@riseup.net>
To: supervision@list.skarnet.org
Subject: Re: Have an external script wait for a oneshot service
Date: Fri, 6 Dec 2024 17:11:26 +0100 [thread overview]
Message-ID: <Z1MiLtRwfFO-ecJg@sparta> (raw)
In-Reply-To: <emf0648862-dc16-477c-9f16-8384e1e6720a@6555180b.com>
[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]
>>Assuming s6-rc is used for the main supervision tree and on login,
>>which is fair, since the very thing we discuss about is part of my project
>>doing all of that with s6-rc,
>>this would cause users to need to learn s6 additionally to s6-rc,
>>when s6-rc can be used for all cases.
>
> The vast majority of services a user will want to have are longruns.
>And longruns are run under s6; longrun service definition directories
>are pretty much s6 service directories. I don't think it's honest to
>say "you only need to learn s6-rc, not s6"; the s6-rc learning curve
>*includes* learning at least the fundamentals of s6.
As a matter of fact, I’ve setup “user services” on my computers (services for
one user only actually, I do not care about edge cases since I’m both root and
the regular user) a few months ago with s6-rc, and up til now I only have
longruns.
I do have though dependencies between these longruns, mostly between the user
dbus service and other user-specific services that depend on that thing, like
pipewire.
Not sure it would justify the use of s6-rc, because one could just let pipewire
start and die until dbus is run. Or consider these services do not make sense
when the user is not logged in, so that they will be run by s6-rc on login.
Hoël
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-12-06 16:11 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
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 [this message]
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=Z1MiLtRwfFO-ecJg@sparta \
--to=hoelbezier@riseup.net \
--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).