Joachim Breitner

Debian Ideas: Instance-Capable Init Scripts

Published 2007-03-26 in sections English, Debian.

Debian as a Linux distrubtion is all about integration and ease of management, which includes init-scripts. I’d like to propose a feature that might be helpful to quite a few system administrators while being non-disruptive to all others.

For a lot of daemons there are use-cases that require more than one instance of the daemon to be running. With instance I mean a separate process with it’s own configuration files, but on the same system, which rules out virtualisation or changeroots. Examples are copies of the “main server” running on a different port, to test new settings, different servers on different IPs, a HTTP-Server-Split into a slick static-and-proxying server and a heavy backend server, a mail server split with a virus scanner in between etc.

So as an administrator I currently not only have to write the configuration for the additional instances, but also write my own init scripts and modify them, never being sure if I did it good or whether it will cause problems on package upgrade or similar things. I’d rather see the functionality built-in to the package’s init script directly.

There is a package in Debian that already provides this: The OpenVPN package maintained by Alberto Gonzalez Iniesta allows the user to define new instances of OpenVPN simply by adding a new file to /etc/openvpn/. The file /etc/default/openvpn defines which of these instances are to be started when I or the system start runs /etc/init.d/openvpn start. /etc/init.d/openvpn stop stops all running instances and /etc/init.d/openvpn restart also restarts just the currently running servers. I can easily control a specific instance by adding it’s name (which is the configuration file’s basename) after the command to the init script.

I think these semantics are clear, sensible and non-disruptive and should be available with every Debian package where the administrator might want to run several instances at once: web server, mail server, ftp servers, name servers etc.

In those cases where the daemon is not configured by a single file alone, one directory with the configuration for one instance is needed. Otherwise, I don’t see why this should be a problem. For backwards compatibility, the “normal” configuration file locaction could be an implicit instance called “default” and all additional instances go to their own directory (e.g /etc/ntpd.conf is instance “default”, and /etc/ntpd/public.conf is instance “public”).

Comments welcome.


The idea is not bad, although I think a too ovious way to add new instances of services could lead the beginenrs towards the way to solve problems with instance A by creating instance B and having instance A still sitting around and wasting memory or doing other bad things. For the advanced user something like that would be useful, indeed. It doesn't work for all daemons, though. Samba and netatalk have a lot of paths hardcoded at build time and either do not allow changes to that in the config or just ignore it :\
Another approach to handle the problem is zope's dzhandle. It's missing some features I'd like to have, though.
Probably it's just time to think about replacing the good old init stuff by something faster and better extensible. That would be the first step to do towards a better way to start/top daemons. Replacements for init are enough around, it more a matter of selecting one and using it - and extending it if neccessary.


#1 Bernd Zeimetz (Homepage) am 2007-03-26
Sure, a nicer init system might help here. But waiting for that to happen is a bad idea, IMHO. If every issue would be addressed this way, nothing would happen at all.

And I see that in some cases, this will be hard or impossible, so I’m not calling for it to be policy or anything. Just good practice with a common way for the administrator.
#2 Joachim Breitner (Homepage) am 2007-03-26
Yeah, I think a new init will take a long time, although I'd prefer to have it soon. There's a lot to optimize on the old system, especially on desktops. I really don't care if a server needs one or 5 minutes to start, it doesn't matter as it'll be only rebooted for a new kernel. But some users allready start to ask why booting their desktops takes such a long time.
I've looked trough all the alternatives for init and didn't like a single one. Long way to go :(
A general solution would be good to have, but that's imho nothing that could be done fast.
#3 Bernd Zeimetz (Homepage) am 2007-03-26
upstart (currently available in experimental) already has support for that.
If you add the "instance" flag to an upstart job, you can start multiple instances of it.
#4 Michael Biebl am 2007-03-26
How does upstart take care of programs with hardcoded paths? For example running 2 samba or netatalk daemons using the same binaries will result in a mess, although they're listening on different interfaces (bear with me if those things are configureable in the latest samba - our production machines still use a bit older version).
#5 Bernd Zeimetz (Homepage) am 2007-03-26
It's obvious, that every daemons is configured differently. For some it could be sufficient to simply pass additional flags (like the port number), some can be run by specifying differnt configuration files, for some daemons it won't be possible, because they have hardcoded paths. upstart obviously can't help you in such a case.

Where upstart can help you, is tracking the currently running instance, with the ability to start/stop them independently. E.g. the output of "initctl list" would look like
logd (stop) waiting
test (instance)
(start) running, process 5144
(start) running, process 5201
tty1 (start) running, process 2974
tty2 (start) running, process 2519
tty3 (start) running, process 2521

upstart allows you to stop and start the different instances of a service separately if you pass the --id option to it. Otherwise a stop/start will affect all running instances (similar to the "all" keyword mentioned earlier)

If you need more info on upstart, please let me know.

#6 Michael Biebl am 2007-03-27
How about:
/etc/init.d/service action [instance_name]

With no instance we might assume the 'default' instance. Also we should have the 'all' special instance, especially for use in the stop or restart targets.

It is a nice idea, why don't you make some code to implement this functionality in a generic way and then propose a policy change.

That would be a very nice and useful change.
#7 Aigars Mahinovs (Homepage) am 2007-03-26
That’s pretty much what I propose, just that in your case there is not default set of instances to start if no paramter is given. Note that in your variant there would not be a way to start instances other than the default on system start. But these are details...

If I find some more people that are interested I might hack on that during DebCamp and just offer patches (and inofficial packages somewhere). I do not think this has to be policy, as for some daemons it might just not be useful (portmap?) and others it might just be too hard (samba).
#8 Joachim Breitner (Homepage) am 2007-03-26
The apache2 packages have patches to add this capability rotting away in the BTS since a year or so.
#9 Marc 'Zugschlus' Haber (Homepage) am 2007-03-29

Have something to say? You can post a comment by sending an e-Mail to me at <>, and I will include it here.