First, I need to apologize, because I spend too much time talking and
dismissing ideas, and not enough time coding and releasing stuff. The
thing is, coding requires sizeable amounts of uninterrupted time - which
I definitely do not have at the moment and won't until December or so -
while writing to the mailing-list is a much lighter commitment. Please
don't see me as the guy who criticizes initiatives and isn't helping or
doing anything productive. That's not who I am. (Usually.)
On to your idea.
What you're suggesting is implementing the dependency tree in the
filesystem and having the supervisor consult it.
The thing is, it's indeed a good thing (for code simplicity etc.) to
implement the dependency tree in the filesystem, but that does not make
it a good idea to make the process supervision tree handle dependencies
itself!
(Additionally, the implementation should be slightly different, because
your ./needs directory only addresses service startup, and you would also
need a reverse dependency graph for service shutdown. This is an
implementation detail - it needs to be solved, but it's not the main
problem I see with your proposal. The symlink idea itself is sound.)
The design issues I see are:
* First and foremost, as always, services can be more than processes.
Your design would only handle dependencies between long-lived processes;
those are easy to solve and are not the annoying part of service
management, iow I don't think "process dependency" is worth tackling
per se. Dependencies between long-lived processes and machine state that
is *not* represented by long-lived processes is the critical part of
dependency management, and what supervision frameworks are really lacking
today.
* Let's focus on "process dependency" for a bit. Current process
supervision roughly handles 4 states: the wanted up/down state x the
actual up/down state. This is a simple model that works well for
maintaining daemons, but what happens when you establish dependencies
across daemons ? What does it mean for the supervisor that "A needs B" ?
- Does that just mean that B should be started before A at boot
time, and that A should be stopped before B at shutdown time ? That's
sensible, but it simply translates to "have a constraint on the order
of the wanted up/down state changes at startup or shutdown". Which can
be handled by the init and shutdown scripts, without the need for direct
support in the supervision framework; an offline init script generator
could analyze the dependency tree and output the proper script, which
would contain the appropriate calls to sv or s6-svc in the correct order.
- Or does that mean that every time A is started (even if it is
already wanted up and has just unexpectedly died) the supervisor should
check the state of B and not restart A if B happens to be down ? What
would be the benefit of that behaviour over the current one which is
"try and restart A after one second no matter what" ? If B is supposed to
be up, then A should restart without making a fuss. If B is wanted up but
happens to be down, it will be back up at some point and A will then be
able to start again. If B is not wanted up, then why is A ? The dependency
management system has not properly set the wanted states and that is the
problem that needs to be fixed.
* Supervisors currently have no way of notifying their parent, and they
don't need to. Their parent simply maintains them; supervisors are pretty
much independent. You can even run s6-supervise/runsv without s6-svscan/
runsvdir, even if that won't build a complete supervision tree. The point
is that a supervisor maintains one process according to its wanted state,
and that's it. (With an optional logger for runsv.) Adding a notification
mechanism from the supervisor to its parent (other than dying and sending
a SIGCHLD, obviously) would be a heavy change in the design and take away
from the modularity. It can be done, but not without overwhelming benefits
to it; and so far I've found that all the additional stuff that we might
need would be best handled *outside of* the supervisors themselves.
The more I think about it, the more convinced I am that script generators
are the way to go for dependency management, and service management in
general. Script generators can take input in any format that we want, and
output correct startup/shutdown sequences, and correct run scripts, using
the infrastructure and tools we already have without adding complexity
to them. It's something I will definitely be looking into.
--
Laurent
Received on Fri Oct 31 2014 - 08:05:09 UTC