>Under the hood, s6-svc -w? forks s6-svwait -?, which itself forks
>s6-ftrigrd to monitor the event/ directory. As such, using s6-svc -w?
>without a command is equivalent (though slightly slower) than using
>s6-svwait directly.
Nitpick: (using s6-svc -uwU as an example; -u to tell s6-supervise to
bring the service up, and -wU to wait until the service is up and ready)
"s6-svc -uwU blah" rewrites itself into
"s6-svlisten1 -U s6-svc -u blah" ; it doesn't use s6-svwait.
The difference is that s6-svlisten1 starts monitoring event/ *before*
running the s6-svc -u command, whereas s6-svwait does not synchronize
that way and could only be launched in parallel or after s6-svc. This
avoids a tiny race condition and guarantees that "s6-svc -uwU blah"
always returns as soon as blah is up (and ready).
In the s6-svwait case it doesn't really matter because s6-svwait
always checks the state of the service before processing notifications,
but it's very important in the general notification case, see the
difference between s6-ftrig-wait and s6-ftrig-listen1.
Anyway, yes, Colin is right: "s6-rc -u change foo" blocks until "foo"
*and all its dependencies*, whether oneshots or longruns, are up; for
a set of pure longruns this can be emulated by putting s6-svwait calls
in the run scripts (but for the teardown part you'd need to write the
s6-svc -d + s6-svwait -d sequence by hand). When your dependency graph
includes oneshots, however, you cannot really emulate the functionality.
--
Laurent
Received on Fri Mar 20 2020 - 11:45:20 UTC