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
Received on Mon Apr 27 2015 - 08:47:12 UTC