Re: s6-rc design ; comparison with anopa

From: Colin Booth <colin_at_heliocat.net>
Date: Sat, 25 Apr 2015 19:38:39 +0000

On Sat, Apr 25, 2015 at 12:36:24PM +0200, Laurent Bercot wrote:
> On 25/04/2015 09:35, Colin Booth wrote:
> >I've been having a hard time thinking about bundles the right way. At
> >first they seemed like first-class services along with longruns and
> >oneshots, but it sounds more like they are more of a shorthand to
> >reference a collection of atomic services than a service in their own
> >right. Especially since bundles can't depend on anything it clarifies
> >things greatly to think of them as a shorthand for a collection of
> >atomic services instead of a service itself.
>
> Yes, that's exactly what a bundle is: a shorthand for a collection of
> atomic services. Sorry if I didn't make it clear enough.
>
Sounds good. I was having problems reconciling a bundle as a full
service and the ability to bring down bundle A and have it change bundle
B if there was overlap in member services. In more concrete terms, if we
have bundle web {httpd, php, sql} and bundle java {tomcat, sql} and we
ask to shut down java, if bundles were first-class services than I'd
expect to have s6-rc bring down tomcat and keep sql running since it's a
component of another bundle that still needs to be up.

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.
>
> >As long as A depends on B depends on C, if you ask s6-rc (or whatever)
> >to shutdown A, the dependency manager should be able to walk the graph,
> >find C as a terminal point, and then unwind C to B then finally A. While
> >packagers will screw up their dependency graph, they'll screw it up (and
> >fix it) in the instantiation direction.
>
> If A depends on B depends on C, and you ask s6-rc to shutdown A, then it
> will *only* shutdown A. Hoever, if you ask it to shutdown C, then it will
> shutdown A first, then B, then C. For shutdowns, s6-rc uses the graph of
> reverse dependencies (which is computed at compile time).
>
That's actually what I meant wrt the order. Mostly it was a comment
about how packagers will screw up dependencies but that it'll get
screwed up in the startup direction.
>
>
> >If you have a wireless router running hostapd (to handle monitor mode on
> >your radios) and dnsmasq (for dhcp and dns) you're going to want an
> >ordering where dnsmasq starts before hostapd is allowed to run. There's
> >isn't anything in hostapd what explicitly requires dnsmasq to be running
> >(so no dependency in the classic sense) but you do need those started in
> >the right order to avoid a race between a wireless connection and the
> >ability to get an ip address.
>
> Hmmm.
> If hostapd dies and is restarted while dnsmasq is down, the race condition
> will also occur, right ?
> Since hostapd, like any longrun process, may die at any time, I would
> argue that there's a real dependency from hostapd to dnsmasq. If dnsmasq
> is down, then hostapd is at risk of being nonfunctional. I still doubt
> "ordering" without "dependency" is a thing.
>
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.

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.

Cheers!
-Colin
Received on Sat Apr 25 2015 - 19:38:39 UTC