Bug#727708: init multiple instances of a daemon
This email is not so much about the change of init system but just about
the multiple-instance problem, regardless of which init we use. It is
not a huge hassle but it is something that could be handled more smoothly.
Some packages provide a way to start multiple instances in one shot from
their init script, e.g.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433660
which does it in such a way that a single invocation of the init script
hits all instances (e.g. starting all when you may only want to start one).
This is a situation that may improve by the move to a new init system
but I believe it can also be improved even if we retain sysvinit for
some or all platforms.
My own solution usually involves duplicating the init script, e.g
# cp /etc/init.d/some-service /etc/init.d/some-service-instance2
and then hacking some-service-instance2 to use an alternate daemon
command line, point the daemon to alternate configuration file, PID
file, etc and finally I do
# update-rc.d some-service-instance2 defaults
This means the admin can restart the instances independently. However,
there are still two problems:
a) the additional instances are not restarted automatically by dpkg upgrades
b) depending upon the package, the effort to hack the init script can
vary and potentially many users waste time duplicating these local hacks
Changing to a new init system probably resolves problem (b) because most
of the new solutions are based on a very concise manifest that can be
duplicated easily. If we stick with sysvinit, however, maybe we need to
consider standardizing init scripts using a pattern that supports
multi-instance? Peter's blog suggests one starting point, for example:
http://people.skolelinux.org/pere/blog/Debian_init_d_boot_script_example_for_rsyslog.html
Problem (a) would still remain, however, with all the init solutions as
far as I can tell unless we decide on some mechanism for letting dpkg
know which copies of the init script (or declarative manifest in systemd
or upstart language) are associated with each package. Is that a
specific topic that has already been discussed elsewhere?
Reply to: