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
