unsubscribe
> On 5 Dec 2024, at 01:58, Laurent Bercot <ska-supervis...@skarnet.org> wrote: > > >> >> 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 >
