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? -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52b73f9f.7070...@pocock.com.au