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
