Re: s6-rc design ; comparison with anopa

From: Colin Booth <colin_at_heliocat.net>
Date: Mon, 27 Apr 2015 05:59:16 +0000

Apologies to Laurent who is about to get this one twice.

On Mon, Apr 27, 2015 at 12:48:58AM +0200, Laurent Bercot wrote:
> 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.
>
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? In the grand scheme of things it doesn't matter since
regardless of the method used to start foo, s6-rc will start foo-log and
bar due to the dependency graph. However, I still think it's a
reasonable question since it sheds light into the expected method of
grouping longruns and oneshots.

In hindsight, this question could probably have been better asked as
follows: "does s6-rc automatically create bundles for each complete
dependency chain?" If it doesn't that's totally fine, I'm just trying
to suss out implementation and interaction details well before the ship
date. Actually, it's probably better if automatic bundle creation
doesn't happen beyond daemons and their loggers, since otherwise we'll
end up with totally dumb bundle names like:
"nginx+nginx-log+php-fpm+php-fpm-log+syslogd+syslogd-log+mysql+mysql-
log+net-enable\(boot\)_bundle" :)
>
> 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.
>
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). And yes, in the end everything is user supplied, be it
at the programmer, distro, or end user level, but some people feel like
those differences necessitate using different terminology as well. For
the record, I don't particularly feel like those distinctions warrent
different terminology and handling, but I'm sure folks who don't want
to write their own dependency definitions feel otherwise.

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.
>
> 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.)
>
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. If we can hit the compiled db directly with the same tools and get
meaningful results, than all the better.

Cheers!
-Colin
Received on Mon Apr 27 2015 - 05:59:16 UTC