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.
> 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).
> Will s6-rc make loggers implicit dependencies of services, or will need
> to define that? In other words, if we have a bundle 'ssh-daemon' that
> contains the longruns sshd and sshd/log, will the dependency compiler
> correctly link those so that when you ask the bundle to start it brings
> up sshd/log first, and when you ask it to start it brings down the
> logger last.
Unless there's a compelling reason not to, if there's a "sshd" service
and a "sshd-log" service and there's an annotation somewhere in the
definition of sshd or sshd-log that sshd-log is the logger for
sshd, then s6-rc-compile will automatically create a dependency from
sshd to sshd-log, and ensure that $live/servicedirs/sshd is the servie
directory for sshd and $live/servicedirs/sshd/log is the service
directory for sshd-log.
So yes, when you start the sshd-daemon bundle, s6-rc will start the
logger first and then the daemon, or stop the daemon first and then the
logger.
> Are oneshots assumed (requored) to be idempotent? Or does $live/state
> track if a oneshot has already been fired and no-op if that is the case?
$live/state tracks oneshots, of course. :)
> Not to be too pedantic, but how often do daemons ask for user input? I
> don't know about you, but being required to pass user input on boot is a
> big nono in my book.
Tell that to Olivier. :)
ISTR some encrypted filesystems require a passphrase to be given at
mount time, so this is a real use case. I don't intend to add terminal
support to s6-rc; if the problem comes up, i.e. if several terminal-
using services are started in parallel and conflicts arise, I'll think
of a specific solution in time.
> So components of a bundle can fail and the bundle is still considered to
> be functional? This make sense only if bundles are really tag sets or
> some other loose grouping.
Yes, that's what they are. The atomic services that can be started are
still started; however, the "s6-rc -u bundle" invocation will exit
nonzero, since some atomic services failed. It is then possible to use
some ui to list running atomic services and see what has succeeded and
what has failed.
> 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.
> Shouldn't this be handled prior to Stage-2 handoff? At the tail-end of
> Stage-1 you Try to start a getty along with the catch-all logger. If
> that fails we bring up our debug shell. Assuming it doesn't fail,
> Stage-2 starts, s6-rc does its work, and brings up the `gettys' bundle
> which no-ops on getty-1 (already started) and bring up 2-N. As long as
> s6-rc is constrained to Stage-2 and multiple start attempts on a service
> remain idempotent, we should be able to use the same shell escape-hatch
> mechanisms in the early stages without having to add extra logic
> handling to the application.
Yes, for the initial getty or debug shell, this can be directly handled
in stage 1. For other conditional executions, I think conditionally
running different s6-rc invocations will be enough. In any case, it can
be done outside of s6-rc itself and I don't need to add support for it.
--
Laurent
Received on Sat Apr 25 2015 - 10:36:24 UTC