Thanks Colin! That clarifies a lot.
The s6-rc -wu command was a typo, although I had no clue s6-rc has such an option as well, so the information is still useful. I meant to say s6-svc -wu <service>. Or am I wrong in assuming that that is the equivalent of runit's sv up <service>? I went that route because that is the recommended way to handle dependencies in runit. I take it s6-svwait is preferred in s6, especially given that there is no polling and hence no cost involved? All the best, Uros On Fri, Mar 20, 2020 at 1:00 PM Colin Booth <[email protected]> wrote: > On Fri, Mar 20, 2020 at 12:30:15PM +0800, Uros Perisic wrote: > > If all services are started in parallel, but s6-rc -wu blocks until a > > service is up, what is the difference between simply putting it in a run > > script before the exec call, and s6-rc figuring the dependencies out > ahead > > of time? > > Hi Uros, > > For simple setups (a few longruns) where you know the interdependencies > you are absolutely correct that you could use s6-svwait(1) in run scripts > to control ordering. The hard part comes in two parts: > 1. when you don't know the exact dependency set but know that a service > needs to start after a group of services (lets call it a bundle) are > started and passing their internal checks. > 2. if you need to have an initalization script run *after* a supervised > program is run. For example, the udev coldplug cycle (the thing that > detects existing hardware) needs a running udev in order to create the > device nodes and while you could run that as a forked process in the > udev run script, it really only has to happen once. > > It's these two considerations that caused s6-rc to come to being. While > the first can be handled with a helper function library, the second > cannot without either dumb tricks (supervised processes that set > themselves down at termination, or exec into s6-pause, or the like) or a > system that understands both kinds of services as well as a dependency > ordering system. > > Depending on what you're trying to do, s6-rc may be entirely overkill. > Like I mentioned at the beginning, if all you're trying to do is start a > number of services and some of those depend on others before starting > (for example, a collection of web services and web servers fronting > them probably want to wait until the services have started before > bringing up their corresponding web frontend) then blocking in the web > server run script is totally fine since it's a self-contained service > pair. For 90+% of the process supervision world this is good enough, > it's only when you start managing the lifecycle of full systems > (including containers) or very complex service interdependencies does > the added complexity of a service manager start to make sense. > > Cheers! > > P.S. s6-rc -wu blocks until the *last* service in the start set is up. > If you add some verbosity you'll see multiple services get started, and > then additional ones being executed as their dependencies become > available. > > (1) or s6-svstat -o ready and an exit on failure, or whatever. > -- > Colin Booth >
