From: "Laurent Bercot" <ska-supervision@skarnet.org>
To: supervision@list.skarnet.org
Subject: Re[2]: Have an external script wait for a oneshot service
Date: Wed, 04 Dec 2024 21:58:28 +0000 [thread overview]
Message-ID: <em7af28a17-e9ab-4531-acfe-2be95ab4507e@af2df4ac.com> (raw)
In-Reply-To: <e4831f21-756a-45b9-a69a-9bff1668a652@sopka.ch>
>Although it would be nicer to have a standard way to do this
There is a standard way to block until a oneshot has completed:
depend on that oneshot.
Duh.
The thing is, s6-rc wasn't designed to have external scripts
interacting in this way with this engine, because if you have programs
depending on intermediary s6-rc states, they should be managed by s6-rc
as well. The point is to have a predictable machine state when s6-rc
exits; if you have random other stuff doing things in parallel, that
defeats the purpose.
And with an s6-linux-init setup, at boot time there is no other
process than s6-rc managing your services. You have the supervision
tree, and the stage 2 script, and that's it. And if you're going to
spawn stuff in your rc.init that waits for oneshot X in the s6-rc db,
then... why? Why not have said stuff as another service?
If you cannot, for whatever reason, maybe bring your services up in
two steps?
s6-rc change X && stuff & s6-rc change default
And if all else fails, the generic solution would be to have a oneshot
Y depending on X (so, that would run once X is done) that sends a
notification to a place of your choice via a mechanism of your choice,
you could use a fifodir and s6-ftrig-notify for this. You would still
have to deal with the race conditions around setting up the listener
etc.
The cleanest way to achieve what you want, without support in the
service set itself, is to s6-rc change X first, then s6-rc change the
rest of your services. That way, you avoid breaking abstraction with
hacks of questionable aesthetic value.
--
Laurent
next prev parent reply other threads:[~2024-12-04 21:58 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 ` Laurent Bercot [this message]
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
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=em7af28a17-e9ab-4531-acfe-2be95ab4507e@af2df4ac.com \
--to=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).