Consensus on process "instances"?

From: Avery Payne <avery.p.payne_at_gmail.com>
Date: Fri, 28 Nov 2014 19:35:23 -0800

An occasional theme I see with Debian's approach to init.d scripts is to
manage multiple instances of a process, so that a single script brings up
or down a set of processes. buildbot is one example, where multiple
instances of the same program are started for different settings.

The simple approach to obtaining this behavior would be to write a
definition for each instance. This provides a very fine control over what
is and isn't running but the maintenance of it is increasingly prohibitive
with each instance added. For larger installations, I don't see this as
practical to maintain.

A possible solution would be to create a separate svscan directory, use the
same script for each instance with separate per-instance settings, and
start all of the instances as a process sub-tree of the parent svscan. A
crudely-drawn example follows:

svscan /etc/service
  -> supervise buildbot-master
    -> svscan /etc/service/buildbot-master/instances/
      -> supervise buildbot-1
      -> supervise buildbot-2

This is very tidy, but it only eliminates a fraction of the work. The only
advantage I can find is that there wouldn't be a need to write a new script
for each instance. While the script can be debugged once and re-used
repeatedly, each setting is still done by hand with the potential for
errors. So this solution is only marginally better, and has the same
maintenance problems.

Is there a better way to accomplish this, or a common consensus about how
to handle this situation? Or do people simply deal with the pain of
writing all of the instances as they are needed?
Received on Sat Nov 29 2014 - 03:35:23 UTC