On 27/04/2015 07:59, Colin Booth wrote:
OpenSSH, at least on Linux and *BSD, chroots into an empty directory after forking for your login. That was an example but I think the question is still valid: if you have a logical grouping of longrun foo, longrun foo-log, and a oneshot helper bar, where foo depends on foo-log and bar, does s6-rc automatically create a bundle contaning foo, foo-log, and bar?
No, because it cannot tell where the logical grouping will end. Chances are that bar, or foo, or foo-log, depends on something else; you don't run services, or even service groups, in a void - see below.
In hindsight, this question could probably have been better asked as follows: "does s6-rc automatically create bundles for each complete dependency chain?"
No, and not only because of the naming - just because it would not make sense to shutdown such a bundle. If foo-log depends on a "mountvarlog" oneshot that mounts /var/log because foo-log logs into /var/log/foo, and mountvarlog depends on a "mountvar" oneshot, then an automatic "foo-bundle" would include foo, foo-log, mountvarlog, and mountvar. Shutting down foo-bundle would shut down everything in the bundle, so it would bring down everything that depends on /var and /var/log, then unmount /var/log, then unmount /var. That is probably not what you want. :) A bundle is only a good idea when it makes sense to bring all its contents up or down at the same time. This is the case for a daemon and its logger; this is the case for a runlevel. This is not the case for a complete dependency chain, which you don't need to bundle since s6-rc will properly act on dependencies anyway.
It's mostly a distinction of "does service foo start but maybe not do the right thing if bar isn't running" (httpd and php-fpm) vs. "does service foo crash if bar isn't running" (basically everything that depends on dbus).
Call me uncompromising, but I don't think "start but maybe not do the right thing if bar isn't running" is a useful category. Either foo can work without bar or it cannot; the unwillingness to make a decision about it is unjustified cowardice - uncertainty and grey areas bring nothing but suckiness and pain to a software system. If the user decides that foo can work without bar, then fine: he won't declare a dependency from foo to bar. If he decides otherwise, he will declare such a dependency. But s6-rc will not provide support for wishy-washiness.
Also, by no means was I trying to imply that s6-rc should deduce anything. If anything I was saying that, as an SA, being able to take implicit dependencies that mostly exist in the form of polling loops in run scripts and other such hackery (such as my wireless setup) and rewrite them as explicit dependencies for the state manager to manage sounds great and is probably the part of s6-rc that I'm most excited about.
Well, yes, that's the only reason why I think a real state manager can be useful :)
Low-surprise interoperability with standard unix tools mostly. Assuming the compiled format isn't human readable, having the functionality to do a human-readable dump to stdout (so people can diff, etc) is totally fine.
Yes, that's planned.
If we can hit the compiled db directly with the same tools and get meaningful results, than all the better.
The db is in binary form, so you'll need the dumping tool. -- Laurent