On 25/04/2015 21:38, Colin Booth wrote:
> This actually brings up another question, is there any provision for
> automatic bundling? If sshd requires sshd-log and a oneshot to create a
> chroot directory does s6-compile also create a bundle to represent that
> relationship or do we need to define those namings ourselves. This is
> the inverse of my question about loggers being implicit dependencies of
> services.
I'll probably add an automatic bundling feature for a daemon and its
logger; however, a oneshot to create a chroot directory? That's too
specific. That's not even guaranteed portable :) (chroot isn't in Single
Unix.) If you want a change from the default daemon+logger configuration,
you'll have to manually set up your own bundle.
> It depends on the persons setup. In my case it's a user-supplied
> dependency since there's nothing intrisic to dnsmasq or hostapd that
> reqires them to run together which I currently get around by polling for
> dnsmasq's status from within the hostapd run script. All in all it's a
> semantic difference between dependencies that are needed to start
> (dependencies), and depenencies that are needed for correct functioning
> but are not needed to run (orderings). The nice part is that while there
> is a slim difference between the two, all the mechanisms for handling
> dependencies can also handle orderings as long as the dependency tracker
> handles user-supplied dependencies. Handling user supplied dependencies
> also simplifies the system conceptually since people won't have to track
> multiple types of requirements.
What do you mean by user-supplied dependencies ? Every dependency is
basically user-supplied - in the case of a distro, the user will be the
packager, but s6-rc won't deduce dependencies from a piece of software
or anything: the source will be entirely made by people. So I don't
understand the distinction here.
> One last thing and I'm not sure if this has been mentioned earlier, but
> how easy is it to introspect the compiled form without using the
> supplied tools? A binary dumper is probably good enough, but I'd hate to
> be in a situation where the only way to debug a dependency ordering
> issue that the compiler introduced is from within the confines of the
> s6-rc-* ecosystem.
The s6-rc tool includes switches to print resolved bundles and resolved
dependency graphs. I will make it evolve depending on what is actually
needed. What kind of functionality would you like to see ?
(There is also a library to load the compiled form into memory, so writing
a specific binary dumper shouldn't be too hard.)
--
Laurent
Received on Sun Apr 26 2015 - 22:48:58 UTC