>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
Received on Wed Dec 04 2024 - 22:58:28 CET