Re: Request for Comments: Standardize enabling/disabling of system services
On Wed, Apr 01, 2009 at 05:03:27PM +0200, Patrick Schoenfeld wrote:
> We also don't seem to have a clear consense how to disable/temporarily
> deactivate services. The current situation is that some packages include
> a file in /etc/default with a variable "RUN", "RUN_<PACKAGENAME>",
> "START_ON_BOOT" or even another possible name
> which decides weither a service runs when invoke-rc.d <service> start
> is issued or not. Some other packages do not follow this approach
> and start or don't start as the maintainer sees fit.
> There are clear disadvantages with this:
> - The administrator has no way to influence the decision weither
> a service shall run directly after installation.
policy-rc.d in conjunction with /etc/default does this, but that's unduly
complex; and anyway,
> - The administrator needs to apply and know about several different
> ways about how to enable/disable services.
- It causes conffile prompts when the package is upgraded.
- It requires launching an editor.
- The /etc/default/ files are sourced by the init scripts, which means
they're intepreted by the shell, with all the syntactic pitfalls that
implies.
- It neuters the init script, when all you normally want is to affect the
policy while leaving intact the admin's ability to run the init script by
hand (e.g., for testing purposes)
> I know there are constraints where a local-admin decision "start/don't
> after installation" cannot be followed. Still, I would like to work
> on the following idea and implement it somewhere during the
> squeeze (or +1) release cycle.
> --- IDEA START ---
> * We establish the practice, that by default no package does include
> an enabled RUN_<SERVICE> variable in its /e/d/<packagename> file. Instead
> every service shall include such a variable, but commented. The default
> of the init script should be to start, unless RUN_<SERVICE> says different.
> The name of the variable should be standardized to RUN_<SERVICE>.
No, because /etc/default/* are the wrong interface for this for the reasons
described above.
> * We add a new configuration file (possibly /etc/rc.conf because thats
> a file that exists in different distributions and has a similar meaning)
> which can have the following configuration settings:
> * RUN_NEW_SERVICES_AFTER_INSTALL=<yes|no|1|0|true|false>
> * RUN_<SERVICE>=<yes|no|1|0|true|false>
Please first specify the interfaces (how this interacts with invoke-rc.d,
how it interacts with runlevel configuration, how the user configures it)
and specify the config file format afterwards. The format should follow
naturally from the interface requirements; I don't think the above meets
our needs at all.
> * We let the maintainer scripts respect the RUN_NEW_SERVICES_ON_INSTALL
> setting on a new installation.
The invoke-rc.d interface already handles this part; this would basically
mean providing a policy-rc.d that honors your new config file.
> * We develope a policy.d layer that respects the RUN_<SERVICE> settings from
> rc.conf and /e/default/* and permits/denies start of services, based
> on these settings. Init scripts shall only start if the service is allowed
> to start (RUN_* setting or RUN_NEW_SERVICES_ON_INSTALL) and if they have
> a sensible default configuration (which pays due to the
> before mentioned contraints). This policy.d layer should be of priority
> Standard. Eventually we should extend the policy.d concept in a way that
> permits to have more than one policy.d layer at a time, so that a user can
> still use an (additional) own layer.
If you mean "policy-rc.d" here, then no; policy-rc.d is specified to do
something else, and we shouldn't overload its meaning. (I think policy-rc.d
is terribly overengineered and underdocumented anyway, and that this is a
significant factor in its slow uptake - we should avoid repeating those
mistakes.)
> * A bonus would be to have a utility to enable/disable services.
Far from being a bonus, I think this is fundamental to the success of any
plan to improve init script handling.
> I post this as a proposal/request-for-comments to debian-devel, because
> I'd like to hear if anybody thinks working on this is valueable and
> because I'd like to know, who is interested to actually work on this idea
> (besides myself). I also hope that some of you have some ideas
> to enhance the idea.
While I don't have time to work on it, I'm certainly eager to see
improvement in this area; every added /etc/default/* file makes me grimace.
If you can make progress here, I will be happy to see it.
If you manage to get the interfaces and high-level abstractions right, there
may be an opportunity here to collaborate with Ubuntu on making the same
system work with upstart? The long-term goal for upstart in Ubuntu is to
migrate away from sysv-rc init scripts to upstart jobs, which addresses the
various problems of concurrency, dependency management, and service
supervising; if Debian and Ubuntu could collaborate on a common service
management interface, that might help scare up the manpower you need.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: