Part of the temptation I've been fighting with templates is to write "the
grand unified template", that does it all. It sounds horrible and barely
feasible, but the more I poke at it, the more I realize that there is a
specific, constrained set of requirements that could be met in a single
script...under the right circumstances. The reality is there will be more
than one template in this arrangement. One that is "simple service", one
that covers the unique needs of "getties", one that needs a
"var/run-and-pid" (which is just simple-service with extras), and one that
I haven't done yet that I call "swiss army knife", the script of scripts.
There are still lots of "one-offs" that will be needed, and that shows the
limits of what can be done. All of these solve the current issues with
process management, and as Laurent has pointed out, *none* of them address
service management. As a stop-gap, until service management is really
ready, the plan is to temporarily patch over the issue by having smaller
processes manage the state of services, and then controlling it through
process management (and again, Laurent has pointed out this is
sub-optimal). An example is using per-interface instances of dhcpcd (no,
not *dhcpd*) to manage each interface. This is heavy and bloats up the
process tree for larger systems because a single process is needed for each
instance of state to manage, when the kernel itself is already
using/managing that state.
With regard to coming up with something akin to a domain-specific language
in the form of a specification for services, this is ideal and solves
plenty. I would love, love, LOVE to see a JSON specification that addressed
the 9+ specific needs of starting processes as a base point, and then
extend it to provide full service coverage, becoming a domain-specific
language that encompasses what is needed. This would be backwards
compatible with daemontools/runit/s6 (within the limitations of the
environment), forwards compatible with future service management, and would
completely supplant the need for templates. I'd like to hear more.
On Fri, Oct 31, 2014 at 2:40 AM, John Albietz <inthecloud247_at_gmail.com>
wrote:
> Script generators are the way I've been leaning.
>
> It's really convenient to have one or more services defined in some kind
> of structured data format like yaml or json and to then generate and
> install the service scripts.
>
> I wish there was a standard format to define services so the generator
> could take one input file and output appropriate service scripts for
> different process supervisor systems.
>
> Anyone seen any efforts in this direction? Most upstart and sysv scripts
> have standard boilerplate, so it looks like there are common standards that
> could be derived.
>
> - John
>
> > On Oct 31, 2014, at 1:05 AM, Laurent Bercot <ska-supervision_at_skarnet.org>
> wrote:
> >
> >
> > 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 - 19:12:43 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:18 UTC