Avery Payne:
But from a practical perspective there isn't anything right now that
handles
dependencies at a global level.
Now you know that there is.
The nosh design is, as you have seen, one that separates policy and
mechanism. The service-manager provides a way of loading and unloading
services, and starting and stopping them. The dependency system is
layered entirely on top of that. Whilst one can use
svscan/service-dt-scanner and svc/service-control and have things run
the daemontools way, one can alternatively use the
start/stop/enable/disable subcommands of system-control and have service
dependency management instead.
The trick is that dependency management is calculated by the
system-control program. When you tell it "systemctl start
workstation.target" it follows all of the wants/, required-by/, and
conflicts/ symbolic links recursively to construct a set of start/stop
jobs for the relevant services. Then it follows the after/ and before/
symbolic links to turn that set into a ordered graph of jobs. Finally,
it iterates through the graph repeatedly, sending start and stop
commands to the service manager for the relevant services and polling
their statuses, until all jobs have been enacted.
conflicts/ is actually easy, although it took me two tries. If
"A/wants/B" exists, then a start job for A creates a start job for B.
If "A/conflicts/B" exists then a start job for A creates a stop job for B.
The important point is that the service manager is entirely ignorant of
this. It is just told to start and stop individual services, and it
knows nothing at all of dependencies or orderings. (A dependency is not
an ordering relationship, of course, but the manual page that I said to
read has already explained that. (-:) It's all worked out outwith the
service manager.
Which means, of course, that it is alterable without changing the
service manager.
And indeed, nosh demonstrates such alteration in action. The
dependency-based system that one gets with system-control is one of two
alternative policies that come in the box; the other being an old
daemontools-style system with a /service directory and ./log
relationships, as implemented by the service-dt-scanner (a.k.a. svscan)
daemon.
Again, the trick is that the daemontools-style stuff is all worked out
in svscan, and the service manager proper has no dealings in it. The
service manager provides a flexible plumbing layer. Higher layers
decide how they want that plumbing put together.
