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
